I haven't done any benchmarks yet so not sure. In addition to the guards I think the use of Proxies will cause some slowdown. But you're right the JIT should be able to optimize most of those guards away (maybe even someday use the guards to help in their optimizing/tracing...just speculating here, I'm not a compiler/JIT guy).
If you compile with "coffee -c" (compile, no contracts) instead of "coffee -cC" (compile, with contracts) you get pure JavaScript, no contracts and no runtime checks. Exactly what vanilla CoffeeScript would have given you.
Well, CoffeeScript/JavaScript doesn't have a static type system. And to add one would be...hard.
But we would still like to express and enforce some invariants about our code. And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."
Contracts also allow us to check invariants that might not result in a run-time exception but could lead to the code just being subtly wrong.
> Well, CoffeeScript/JavaScript doesn't have a static type system. And to add one would be...hard.
Indeed it would be. That said, CoffeeScript is a compiler of sorts.
> And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."
This doesn't really seem to solve that problem. It just throws consistent errors if the types don't match. Your code would likely throw its own error if you didn't check the type manually. In my experience, native js errors are as easy or easier to track down that throwing errors yourself.
> Contracts also allow us to check invariants that might not result in a run-time exception but could lead to the code just being subtly wrong.
Ah, ok. That makes more sense. They're like python decorators, only single purpose.
> Indeed it would be. That said, CoffeeScript is a compiler of sorts.
The fact that we have a compiler doesn't give us all that much. Adding types to a dynamic language (where things can be monkey patched, evaled, and just generally mutated willy-nilly) is a hard problem (not impossible but definitely research [1 and 2 to start, but much more]).
>> And we'd like to do it in a more elegant way than constantly writing "if(argument === ...) then ... else ..."
> This doesn't really seem to solve that problem.
It solves the problem of elegance :)
> It just throws consistent errors if the types don't match. Your code would likely throw its own error if you didn't check the type manually. In my experience, native js errors are as easy or easier to track down that throwing errors yourself.
Key word there is likely. Like I mentioned, there are some errors that don't result in a run-time error and we might like to check for those too. As a silly example, consider a binary search tree [3] that you want to keep balanced. If you get the balance wrong, there's no immediate fault (no TypeError/NPE).
> Ah, ok. That makes more sense. They're like python decorators, only single purpose.
I guess you could say that. If we had an expressive enough decorator-like system for CoffeeScript we could probably implement contracts with it. CS doesn't have one of course so path of least resistance is to add the contract language extension directly.
I'm not sure that the relationship between types and contracts is all that tenuous.
They both work to enforce program invariants and there's a large overlap in the invariants they can express. Usually contracts are checked dynamically (as in contracts.coffee) but this is not a hard requirement (for example .net's code contracts can be statically checked [1]).
It's a fork of CoffeeScript so it replaces your "coffee" executable. If you don't want to overwrite your normal CoffeeScript compiler just run the contracts.coffee "coffee" executable from its own directory.
If you compile with "coffee -c" (compile, no contracts) instead of "coffee -cC" (compile, with contracts) you get pure JavaScript, no contracts and no runtime checks. Exactly what vanilla CoffeeScript would have given you.