Contracts For CoffeeScript

http://disnetdev.com/contracts.coffee/

by swannodette • 15 years ago

139 34 15 years ago

disnetdev.com

mobileman• 15 years ago

This is just static types

jashkenas• 15 years ago

Not quite.

    isEven = (x) -> 
      x % 2 is 0

    f :: (!isOdd) -> !isEven
    f = (x) -> ...

jvoorhis2• 15 years ago

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.

bilalhusain2• 15 years ago

it doesn't conflict with the prototype operator?

chucknthem3• 15 years ago

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

irrelative2• 15 years ago

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?

chucknthem3• 15 years ago

This is great, it's like Google's compiler library[0] but with run-time checking! Coffee script is still very hard to debug, this should help avoid about 80% of the mistakes I normally make when coding.

[0] http://code.google.com/closure/compiler/

oinksoft• 15 years ago

You're thinking of the Closure Compiler and its annotations, not the Closure Library.

chucknthem3• 15 years ago

Ah you're right, edited

swannodette• 15 years ago

Library author covers the relevant history here, http://disnetdev.com/blog/2011/08/23/Contracts.coffee-Contra...

This Lambda The Ultimate discussion on Benjamin C. Pierce's (Types And Programming Languages) talk Types Considered Harmful is also of interest - the gist being that contracts are useful because sometimes static types are just too damn hard - http://lambda-the-ultimate.org/node/2828

EDIT: Might as well link to Brendan Eich's talk Proxies Are Awesome!, http://www.slideshare.net/BrendanEich/metaprog-5303821. I haven't really been following the Proxy thing and they seem quite useful. It's nice to see them applied so powerfully here.

bilalhusain2• 15 years ago

ok, figured out that it takes care of the existing prototype operator (::) in lexing [1],[2]. It seems little annoying but guess I'll get the hang of it.

[1] https://github.com/disnet/contracts.coffee/blob/master/src/l...

[2] https://github.com/disnet/contracts.coffee/blob/master/src/l...

mhansen• 15 years ago

How does it integrate with the `coffee` executable? Does coffeescript have a compiler plugin system, or are you patching the compiler? Will this cause me problems when I try to update my coffeescript compiler?

disnet5• 15 years ago

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.

I mention this briefly towards the end of the quick start section of the doc: http://disnetdev.com/contracts.coffee/#quickstart

d0m• 15 years ago

I ♥ where it's going! "Nhaa, I won't use a statically typed language.. I prefer javascript with coffeescript syntax. But, I'll use contracts and tests to make it robust." Hands down, it's great and I'll definitely use it.

Also +1 to be able to define your own type.

riffraff• 15 years ago

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 ?

disnet5• 15 years ago

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.

tlrobinson• 15 years ago

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

clyfe• 15 years ago

Can't this be implemented as a DSL? https://gist.github.com/1180516

    guardArgs = (def, args) ->
      i = 0
      for arg, type of def
        throw new Error("bad type of #{arg}") unless typeof args[i] == type
        i++

    typeEnsure = (def, f) -> ->
      guardArgs(def, arguments)
      f.apply @, arguments
        
    myFunc = typeEnsure {name: 'string', i: 'number'}, (name, i) ->
      console.log name, i

    myFunc("foo", 1) # ok
    myFunc("foo", "x") # Error: bad type of i

I think this can be extended to custom types too.

samth• 15 years ago

First, I don't think what you show is a DSL -- it's just some functions. Rather, what Tim has implemented is a DSL.

Second, you need proxies to handle things like functions and mutable arrays.

Third, that there's a DSL for describing contracts is, I think, a large part of the point.

Lamtard• 15 years ago

there seems to be a pure js implementation of contracts around for a while: https://github.com/4z3/contract

the CoffeeScript version is nice though :D

AlexeyMK• 15 years ago

Higher order functions:

  f :: ((Num) -> Bool, Num) -> Bool

The type of f is not particularly obvious to me; instinctively, it could either be:

1. A function that takes (a function from Num to [Bool, Num]) and returns Bool, or

2. A function that takes (a function from Num to Bool) and a Num, and returns a Bool.

Given enough time, I'm going to guess 2, but this makes CoffeeScript's destructing assignment, IE

  [a, b] = func()

feel less 'first class'. Is this a serious ambiguity, or just me not having enough experience with precedence in CoffeeScript/functional languages?

dherman2• 15 years ago

No ambiguity; if you put brackets around it you get a tuple (really, an array of fixed elements), and without brackets, the comma is part of the function signature. If you wanted to express your interpretation #1 you'd write:

    f :: ((Num) -> [Bool, Num]) -> Bool

Dave

Contracts For CoffeeScript

Related Stories