It's something that comes from Haskell. The `where` keyword always starts a new layout/indentation context. It's not strictly necessary and there are ways around it, so it's just a point of consistency.

We found no usages of it in the wild. If there is real-world need for them, we'll consider adding them back.

FWIW I use binary literals a bunch in python, either when working with binary file formats or with bitfields.

Yes, I'm not saying there aren't usages for them in general, but PureScript currently occupies a niche that doesn't get down to the level of binary file formats. This change is more about "only supporting what we need to right now", rather than "we don't like binary literals". As noted elsewhere, it's not difficult to add support for them when we need to.

There aren't native modules in JS (though they are coming in ES6). The module pattern is a way of having private scope by wrapping everything in a closure. So yes, the module pattern just creates a closure and returns an object (or assigns to global scope) with its public members.

A cleaner way of doing the immediately-invoking function in CS is to use a `do` statement.

    MyModule = do ->
      # module body

No need for any parens.

And you don't even need to use assignment. This works as well:

    do ->
      # module body

you don't need to assign it to something, unless you need to assign it to something.

sounds like op was specifically referencing to parens for execution.

Interesting, I looked this up.

> CoffeeScript provides the do keyword, which immediately invokes a passed function, forwarding any arguments.

Apparently in April 2012 they updated the code to make it simulate namespacing.

> A tweak to the semantics of do, which can now be used to more easily simulate a namespace: do (x = 1, y = 2) -> ...

If you're interested in doing some of this stuff in JS, there's sweet.js[1] for macros. I've also implemented some similar stuff as libraries: adt.js[2], matches.js[3], and tailrec.js[4]. By implementing them as libraries, I've given up some of the nicety of native-looking syntax, but it requires no preprocessing and only ES3.

[1] http://sweetjs.org/

[2] https://github.com/natefaubion/adt.js

[3] https://github.com/natefaubion/matches.js

[4] https://github.com/natefaubion/tailrec.js

With pattern matching, the term on the left is a destructuring of the term on the right. Using a static instance like that isn't what you normally do in practice, but rather something like:

    myfoo = Foo(4, Bar(3, 8))
    with patterns:
        Foo(x, Bar(3, z)) << myfoo
        

So in this case, the assertion will only pass if the Foo contains a Bar in the second slot, and that Bar contains a 3 in its first slot, while also binding the 4 and 8 to their own names, x and z respectively.

I find it helps when you use short-circuiting. The returns are the first thing you see, making it more obvious what is going on.

  myfn = (arg) ->
    return 1 if arg is "one"
    return 2 if arg is "two"
    return arg.toInt()

This is obviously a little contrived with such a short method, but helps when you have stuff to do between conditional returns.

Yeah. The example is not very good, as it would probably be better to write as switch expression. But on a complex function, returning early can avoid the need to retain a lot of context in your head while reading that code. I find it especially helpful for returning/throwing on error conditions or breaking out of recursion.

It meshes pretty well as is. If only I could get rid of the strings and redundant arguments.

  mymap = pattern {
    '_, []' : -> []
    'f, [x, xs...]' : (f, x, xs) -> 
      [f x].concat mymap(f, xs)
  }

It shares a lot of the same splat/rest/destructuring syntax.

Check out LiveScript's implicit switch syntax:

http://gkz.github.com/LiveScript/#switch

That's along similar lines, but more like guards in Haskell: http://en.wikibooks.org/wiki/Haskell/Control_structures

You are correct. There is not a guarantee for the future, though I doubt this behavior will change for V8 (this is currently node only). If that scares you, you can use the combinator syntax (check out the readme towards the bottom). The object literal syntax is just sugar for using combinators.

edit: BTW, if you want some precedence in a major library relying on this behavior, look no further than Backbone's router, specifically the `_bindRoutes` method.

Take a look at the next sentence: "Keep in mind, that time is measured in the single microseconds (1µs vs 3µs) to dispatch 5 calls to the same function."

So you are still looking at sub-microsecond dispatch time for a single call. If you look at benchmark/compare.js you'll see how much shorter and clearer the pattern matched function is. I doubt this will put a strain on your performance.

edit: That said, there is likely room for optimizations and speed improvement. It will naturally take longer because it has the overhead of making function calls to the various pattern functions to check if there's a match, instead of having it all inlined like in the hand optimized function.

edit2: Sorry, this was in response to another comment that looks like it got deleted while I was editing. Now its attached itself elsewhere.

Thanks, I misread the first time, made sense the second time! My mistake!

I still have my doubts as to how readable such an approach like this would be in large JavaScript application's when taking into account the already very dynamic nature of JavaScript, but thats more of a personal opinion than anything else.