Reason: [Syntax] Include Haskell where syntax

[ephetic]

From https://github.com/hausdorff/ocaml-where

Haskell's where is pretty great. Say you have a bunch of chained lets, like this:

```-- NOTE: Haskell code; computes (x + 2) * 2
foo x = let y = x+2
let z = y*2
in z

> Gross! The `where` keyword lets you rewrite them in the following lovely, clean way:

```-- NOTE: Haskell code
foo x = z
  where y = x+2
        z = y*2

@hausdorff's sugared Ocaml
(* OCaml version *) let foo x = z where y = x+2 and z = y*2

[hausdorff]

Thanks for the mention. :) It's worth noting, btw, that OCaml itself is implemented with a "revised" OCaml syntax that itself supports where, before it is deleted during the definition of the stock OCaml parser.

You can read more about this and other details about the implementation in my blog post on the subject of implementing this syntax extension.

[SanderSpies]

This translates to

let foo x => {
  let y = x + 2;
  let z = y * 2;
  z
};

and

let foo x => z
  where y = x + 2 and
        z = y * 2;

I'm not seeing the advantage of this proposal directly, I actually had to look twice before I understood what was happening (note: I have close to zero Haskell knowledge). Probably because I'm used to read from top to bottom, and expect the last statement to be the return statement. My expectation is that this will confuse newcomers more then it will help them.

[OvermindDL1]

I'm not seeing the advantage of this proposal directly, I actually had to look twice before I understood what was happening (note: I have close to zero Haskell knowledge). Probably because I'm used to read from top to bottom, and expect the last statement to be the return statement. My expectation is that this will confuse newcomers more then it will help them.

I've seen this when I've taught where to students. It is not worth the pain in teaching it, the inverted flow of code makes it harder to teach and to reason about.

[OvermindDL1]

Also, it adds more white-space sensitivity, which is also painful.

-1 from me.

[hausdorff]

Another problem is that let makes the implicit scoping semantics of where explicit, which can be a big plus, especially when the lets get big and crazy. Also, and tends to imply parallel execution in OCaml, so it's less clear semantically how evaluation works. Haskell gets away with the sloppy scoping semantics here because it is lazy, and (I say this with love) people are generally used to slightly crazy semantics.

The only thing where does well, which I happen to like quite a lot, is to make it easy to put the important things first in a definition. For example, considering some code from a parser I wrote for Python 3, in Haskell, which creates a parser for function definitions:

funcdef = def <~> id <~> parameters <~> colon <~> body ==> emitFuncdef
  where def   = ter "def"
        id    = ter "ID"
        colon = ter ":"
        body  = suite

Essentially this is a CFG for a function definition. We are concatenating the keyword def with an id, parameters, a colon and body. The details of these definitions are less important than the general concept, and so in cases like this, the where adds quite a bit of clarity IMHO.

So I guess the real question is: what is the cost of this clarity? It's not clear to me from this discussion that it is worth it to this project. :)

[ghost]

make it easy to put the important things first in a definition

This is what I like about where; it's nicely mathematical: "big idea, because things". I like to be able to get the gist without having to go through the details first (and this is essentially the same argument I make to peers about using map/filter over naked loops). I'll try to think of more motivating examples, but I'm happy to see the discussion go whichever way.

[OvermindDL1]

make it easy to put the important things first in a definition

In my opinion, especially as teaching these kind of things at times, instead of using where, it is better to break out in to more functions if it really is getting 'too complex' for let's. ^.^

[ghost]

I have also been a programming teacher and I feel where with local helpers seems like good top-down/encapsulated thinking, but I've been cursed to only teach Java et al, so those two statements aren't strictly related.

[jFransham]

I'd say where works well in a language with lazy evaluation and a (to be frank) crap scoping system. You can very nicely write

let something = {
  let first_thing = 1;
  let second_thing = 2;
  first_thing * second_thing
};

but the equivalent in Haskell would be

something =
  let firstThing :: Int
      firstThing = 1
      secondThing :: Int
      secondThing = 2
  in
    firstThing * secondThing

Which is not as easily extractable like the Reason one is. Each line has individual meaning in the Reason code, and can be extracted to a top-level binding. That's not true with Haskell, you have to drop the let and/or drop the in, plus moving the type annotations out and it generally requires a bit of faff. With where, you can write:

something = firstThing * secondThing
  where
    firstThing :: Int
    firstThing = 1
    secondThing :: Int
    secondThing = 2

and now you can remove the local bindings and tab them back and voila, top-level bindings. You don't have inconsistent indentation and two places to remove text. The type annotation and assignment syntax in Reason is the same no matter where you define it, so you'd be fixing what ain't broke.

[jaredly]

gonna close this due to inactivity. feel free to bring up again in the context of the new syntax if you like