Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah I went back and forth on this a little bit. If all variables are defined at the beginning of the `let` expression, you can't rebind a variable like this (assuming some previous `x`):

    let x = x + 1
because the new `x` shadows the old one before `x + 1` is compiled. But if you're defining a recursive function, like this:

    let foo = \n -> foo(n + 1)
you need `foo` to be defined before you compile the lambda body, or else the compiler will think you're referencing an undefined variable.

At one point I had an exception where, if the value of a variable being defined is a lambda, it defines the variable first to allow recursion, but not otherwise. But this felt inconsistent and kind of gross. Instead, I decided to have `def` expressions behave like that, and disallow recursion in `let`. `def` is always a function definition, so you'd almost always want that behavior, and I felt that since it has a different syntax, slightly different assignment semantics wouldn't be so bad.

For mutual recursion you have to go a little further, and find all the definitions in the block before you start compiling anything. So `def` expressions are also hoisted to the top of the block and pre-defined at the beginning. This felt ok to me since `def` expressions look like big, formal, static definitions anyway, and it didn't seem surprising that they would have whole-block scope.



For my hobby language, I figured let rec should be the default and let nonrec the marked case, for exactly the rebinding application. However, it's been over a year since I came to that conclusion, and I still haven't gotten around to implementing the nonrecursive path. (but: mine is very no-moving-parts Immutable, so ymmv)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: