Looking at the generated code, we have a couple issues that prevent full optimization. One of them I already knew about (https://bugs.swift.org/browse/SR-2926) -- as a debugging aid, we guard every trap we emit with the equivalent of an `asm volatile("")` barrier, because LLVM will otherwise happily fold all the traps together into one trap. We really want every trap to have a distinct address so that the debugger can map that trap back to the source code that emitted it, but the asm barrier prevents other optimizations as well. As for `reduce`, it looks like the compiler does inline away the closure and turn the inner loop into what you would expect, but for some reason there's more pre-matter validation of the array than there is with a for loop. That's a bug; by all means, reduce is intended to optimize the same.
Clay has shared and unique pointer implementations in its library. Naive channels could be mostly implemented in the library as well, but I think they might need language support to pull some of the tricks Rust and Go do to make them fast, and Clay's type system would need to better guard against unintended sharing to make them safe. The Rust and Go developers are contributing the groundwork for lightweight tasks into LLVM, so with runtime library support Clay could potentially inherit that support. I think a region type system would fill in the safety holes; the Deca language (http://code.google.com/p/decac/) is very similar to Clay (no runtime requirements, variant-based dynamic dispatch) and successfully uses region typing to provide safe memory access.
Clay is a lot more flexible and metaprogrammable than Rust. Clay allows ad-hoc overloading with predication based on arbitrary compile-time computation, whereas Rust's polymorphism support is more strictly based on Hindley-Milner parametric polymorphism and type classes. On the other hand, Rust, by baking features like shared/unique pointers and logging into the language, is able to provide much stronger safety guarantees with a much simpler type system than Clay would need to provide the equivalent guarantees. Rust also requires a runtime, which supports some cool features like lightweight tasks, cycle collection, and builtin logging, whereas Clay sticks to a "no runtime other than libc" mandate. Overall, Rust will probably be a much better choice for large-scale application development than Clay. The cool thing about Clay is that it's like a scripting language for LLVM. It's great for flexibly generating small amounts of native code without runtime dependencies.
You're correct; Clay's type system doesn't help much with memory safety. It's flexible enough to express RAII-based ownership semantics like C++, so you can manage dynamic memory with reference counted, uniquely-owned, or other policy-enforcing pointer objects, but also like C++, the language doesn't prevent you from taking nonowning references to arbitrary data behind the type system's back and using those references after the owning object has freed the data.
The more fundamental mismatch is that they're testing an interpreter (libc's printf implementation) against a compiler (pypy's format string jit). A C++0x or D library that parsed format strings at compile time would likely still beat pypy.
If you're banned here, you aren't locked out of the site or prevented from posting. Your posts are just marked so that only you (and other users who have chosen "show dead comments" in their preferences) can see them, and there's no indication that you've been blacklisted. It's terrible.
jashkenas (CoffeeScript author) replied to you, but for some reason he's deadbanned:
> Thanks for mentioning it -- the fix was actually to correct a regression from a previous commit, not a true bugfix versus 1.0.1. I've removed that line from the changelog.
Sad, but understandable. "OpenBSD writes their own ROFF interpreter" isn't very interesting, but "OpenBSD purges C++ from core" appeals to developers' strong emotional responses toward C++.
Not everywhere needs to become Silicon Valley. IT is well-trodden ground with established players and power centers now. Smaller cities like Portland would do better promoting emerging industries than trying to catch up to the web startup bus 15 years after it left the station.
Every Mac still ships with Xcode on the OS install disc, as do the OS X upgrade discs. Let's wait until Lion comes out before assuming that won't be the case anymore.
The language in the standard may have changed in C99 due to unprototyped functions being deprecated. In C89, however, I'm pretty sure that unprototyped and prototyped functions need to have compatible calling conventions. In practice, there's no platform I know of where a prototyped function cannot be called as a variadic or unprototyped function (barring special platform-specific ABIs like stdcall that weren't designed for C). Some RISC-style ABIs with pass-by-register and shadow space will fail in the reverse case (a variadic function called as a fully prototyped function) since the shadow space doesn't get populated by the caller for a fully prototyped function, but for a variadic call site, both the shadow space and parameter registers will be populated, specifically to allow prototyped functions to be called as unprototyped.
This is incorrect. It's not possible to implicitly use an incompatible ABI for prototyped and vararg functions, since a foo f(bar, bas) function needs to be callable via an unprototyped foo (* )() pointer. Thus, even prototyped C functions need to use a caller-cleanup convention. To use the callee-cleanup convention, the entire Win16 and Win32 apis are annotated with explicit __stdcall attributes and are addressed by distinctly-typed (__stdcall * ) function pointers, of which no vararg variation is allowed.
I wonder if they'll stick to this for the final version. They tried to remove 256-color mode support in 10.5.something but backpedaled when the Mac Starcraft players went nuts.
There are lots of edge cases where the sign of zero affects computation. In floating-point, zero values represent not only the exact value zero but the result of an underflowed computation too small to represent as a non-zero floating point value, so retaining the sign is often important to at least keep such computations on the correct side of a branch cut or limit. For example:
That's just for the framebuffer. All the intermediate textures flying around will need four times the memory too, and could easily eat up several hundred megabytes.