[Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]
es at ertes.de
Wed Jul 10 19:44:46 CEST 2013
Donn Cave <donn at avvanta.com> wrote:
> > Let is "recursive" because, unlike in the case of other languages,
> > variables are not locations for storing values, but the expressions
> > on the right side of the equality themselves. And obviously it is
> > not possible for a variable-expression to be two expressions at the
> > same time. The recursiveness is buildt-in. It comes from its pure
> > nature.
> I'm surprised that it would come down to purity. It looks to me like
> simply a question of scope. I had to write an example program to see
> what actually happens, because with me it isn't "intuitive" at all
> that the name bound to an expression would be "visible" from within
> the expression itself. I suppose this is considered by some to be a
> feature, obviously to others it's a bug.
In a non-strict-by-default language like Haskell it's certainly a
feature. A sufficiently smart compiler can figure out whether a
definition is recursive or not and apply the proper transformation, so
from a language-theoretic standpoint there is really no reason to have a
I think the proper solution is to identify the underlying problem:
general recursion. Haskell does not enforce totality. I'd really love
to see some optional totality checking in Haskell. If Oleg decides not
to use a state monad, he will still have to be careful not to confuse
the numbers, but if he does, then the compiler will reject his code
instead of producing <<loop>>ing code.
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Haskell-Cafe