I believe jashkenas' example defines both a pre-condition and a post-condition, specifying that f accepts only odd numbers and returns only even numbers ('!' here is the operator for new contract, rather than logical negation). If f is called with anything other than an odd number, an error will be thrown right away, before the body of the function is run.
Those '!'s are really confusing. From the example in the submission:
isEven = (x) -> x % 2 is 0
isOdd = (x) -> x % 2 isnt 0
addEvens :: (!isEven) -> !isOdd
addEvens = (x) -> x + 1
I am guessing that both '!'s define a new contract - and also guessing that coffeescript does not actually have a '!' operator for logical negation. So that addEvens simply takes an even number and returns an odd number.
I find it confusing that the different syntax highlighting of the two '!' suggests (wrongly) that they have different meanings. Also, logical negation is something often used with isOdd/isEven functions.
CoffeeScript does allow ! for negation, but contracts have their own syntax and semantics separate from the rest of the language. It's a little confusing initially, but I suppose there aren't a lot of good operators left. There are a lot of similar convenient inconsistencies that people hardly notice once they sink in:
• Indentation shifts mean different things depending on context (could mean we're doing an object literal, could mean we're defining a function, could mean we're entering a loop, etc.)
• Looping through arrays uses "in" while looping through everything else uses "of"
• Array and object literal syntax might create arrays and objects or define variables depending on which side of the equals sign you're reading
How is this different than creating an OddNumber and EvenNumber type that check their input in the constructor at run-time? That is the point of a type system.
Scala can make this really transparent and concise using an abstract class to implement most of the plumbing and implicit type conversion to automatically convert the contract enforcement types to and from the native types.
case class EvenNumber(val x: Int) extends Contract[Int] {
require(x % 2 != 0)
}
That while this looks like a good extension to CoffeeScript, it's unfortunate that Haskell's type syntax was appropriated when the relationship between contracts and types is tenuous at best.
There are good uses for static type checkers and design by contract, but neither one is a good substitute for the other.
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 grammar hack, but IMO an intuitive one: if you have whitespace around the ::, it's a contract annotation; otherwise it's the prototype operator.
To quote Jeremy Ashkenas's JSConf talk on forking CoffeeScript: "when in doubt, cheat." ;-P