Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Contracts For CoffeeScript

disnetdev.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Contracts For CoffeeScript

#21

Post by 6ren »

bitsai wrote: post #12
jvoorhis wrote: post #5

Earlier quoted context omitted.

Not hardly. The runtime can detect that a function invocation violates a post-condition only after all of that function's side-effects have been run.

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.

Re: Contracts For CoffeeScript

#22

Post by chc »

6ren wrote: post #21
bitsai wrote: post #12

Earlier quoted context omitted.

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…

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

Re: Contracts For CoffeeScript

#23

Post by dherman »

bilalhusain wrote: post #9
jashkenas wrote: post #3

Earlier quoted context omitted.

Not quite. isEven = (x) -> x % 2 is 0 f :: (!isOdd) -> !isEven f = (x) -> ...

it doesn't conflict with the prototype operator?

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

Re: Contracts For CoffeeScript

#24

Post by irrelative »

chucknthem wrote: post #4
mobileman wrote: post #2

This is just static types

No, if you read the article, contracts are enforced at runtime!

I feel a little bit crazy because no one else has brought this up yet, but what's the point of declaring types if your errors don't get caught at compile time? If they're going to throw errors at runtime, how is that an improvement over not checking the types?

Re: Contracts For CoffeeScript

#25

Post by disnet »

irrelative wrote: post #24
chucknthem wrote: post #4

Earlier quoted context omitted.

No, if you read the article, contracts are enforced at runtime!

I feel a little bit crazy because no one else has brought this up yet, but what's the point of declaring types if your errors don't get caught at compile time? If they're going to throw errors at runtime, how is that an improvement over not checking the types?

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.

Re: Contracts For CoffeeScript

#26

Post by irrelative »

disnet wrote: post #25
irrelative wrote: post #24

Earlier quoted context omitted.

I feel a little bit crazy because no one else has brought this up yet, but what's the point of declaring types if your errors don't get caught at compile time? If they're going to throw errors at runtime, how is that an improvement over not checking the types?

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…

> 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.

Re: Contracts For CoffeeScript

#27

Post by disnet »

irrelative wrote: post #26
disnet wrote: post #25

Earlier quoted context omitted.

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…

> 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 o…

> 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.

[1] http://ecee.colorado.edu/~siek/blame-forall-2011.pdf

[2] http://dl.acm.org/citation.cfm?id=1863561

[3] https://github.com/disnet/contracts.coffee/blob/master/test/...

Re: Contracts For CoffeeScript

#28

Post by riffraff »

very cool project! Out of curiosity, what is the overhead of a program with-contracts vs one without them? It kind of looks like a JIT should be able to optimize away most of the guards.

Also, I believe other DBC platforms had options to disable run time enforcing of contracts, is this possible somehow with CFCS ?

Re: Contracts For CoffeeScript

#29

Post by disnet »

riffraff wrote: post #28

very cool project! Out of curiosity, what is the overhead of a program with-contracts vs one without them? It kind of looks like a JIT should be able to optimize away most of the guards. Also, I believe other DBC platforms had options to disable run time enforcing of contracts, is this possible somehow with CFCS ?

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.

Re: Contracts For CoffeeScript

#30

Post by tlrobinson »

Neat. I built runtime argument and return value type-checking into Objective-J awhile back (not enabled by default due to performance overhead). It was really easy since we already declare Objective-J argument and return value types, and we can easily intercept every Objective-J message invocation.

https://github.com/cappuccino/cappuccino/blob/master/Objecti...

Post reply on HN