Donn Cave <> 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
non-recursive let.

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.

Attachment: signature.asc
Description: PGP signature

Haskell-Cafe mailing list

Reply via email to