In my opinion, when you are rebinding a variable with the same name, there is usually another way to structure your code which eliminates the variable. If you would like to write: let x = foo input in let x = bar x in let x = baz x in instead, write baz . bar . foo $ input If you would like to write let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in instead, use a state monad. Clearly this will not work in all cases, but it goes pretty far, in my experience. Edward Excerpts from Andreas Abel's message of Wed Jul 10 00:47:48 -0700 2013:

Hi Oleg,

just now I wrote a message to haskell-prime@haskell.org to propose a non-recursive let. Unfortunately, the default let is recursive, so we only have names like let' for it. I also mentioned the ugly workaround (<- return $) that I was shocked to see the first time, but use myself sometimes now.

Cheers, Andreas

On 10.07.2013 09:34, oleg@okmij.org wrote:

...

Andreas wrote:

...

The greater evil is that Haskell does not have a non-recursive let. This is source of many non-termination bugs, including this one here. let should be non-recursive by default, and for recursion we could have the good old "let rec".

Hear, hear! In OCaml, I can (and often do) write

let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ...

In Haskell I'll have to uniquely number the s's:

let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ...

and re-number them if I insert a new statement. BASIC comes to mind. I tried to lobby Simon Peyton-Jones for the non-recursive let a couple of years ago. He said, write a proposal. It's still being written... Perhaps you might want to write it now.

In the meanwhile, there is a very ugly workaround:

test = runIdentity $ do (x,s) <- return $ foo 1 [] (y,s) <- return $ bar x s (z,s) <- return $ baz x y s return (z,s)

After all, bind is non-recursive let.

On 10.07.2013 10:16, Ertugrul Söylemez wrote:

oleg@okmij.org wrote:

...

Hear, hear! In OCaml, I can (and often do) write

let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ...

In Haskell I'll have to uniquely number the s's:

let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ...

This isn't a case for non-recursive let. It is one of the rare cases where you might actually consider using a state monad.

Except when you are implementing the state monad (giggle): http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Mon... -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

I think that a non-non recursive let could be not compatible with the pure nature of Haskell. 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. For a non recursive version of let, it would be necessary to create a new closure on each line, to create a new variable-expression with the same name, but within the new closure. A different variable after all. That is what the example with the Identity (and the state monad) does. So I think that the ugly return example or the more elegant state monad alternative is the right thing to do. 2013/7/10 Ertugrul Söylemez

oleg@okmij.org wrote:

...

Hear, hear! In OCaml, I can (and often do) write

let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ...

In Haskell I'll have to uniquely number the s's:

let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ...

This isn't a case for non-recursive let. It is one of the rare cases where you might actually consider using a state monad.

Greets, Ertugrul

-- 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.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alberto.

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. Greets, Ertugrul -- 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.

On 10.07.13 6:00 PM, Donn Cave wrote:

quoth Alberto G. Corona,

...

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.

@Alberto: you must have misunderstood my proposal.

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.

Value-recursion *is* useful in a lazy language, e.g. let xs = 0 : xs builds an infinite (in fact, circular) list of 0s. But it is not always meaningful, e.g. let x = x + 1 simply loops. I would like to be in the position to tell Haskell what I mean, whether I want recursion or not.

I've gone to some trouble to dig up an nhc98 install (but can't seem to find one among my computers and GHC 7 won't build the source thanks to library re-orgs etc.) Because, I vaguely recall that nhc98's rules were different here? Anyone in a position to prove me wrong?

I would doubt that nhc98 would interpret let xs = 0 : xs differently than ghc if it implemented anything close to the Haskell 98 standard. But I am not in a position to prove you wrong. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

On 11/07/2013, at 11:09 AM, Donn Cave wrote:

let x = t + 1 in let y = x in let x = y + 1 in x

Still no cigar. nhc98 v1.16 Program: main = print $ (let t = 0 in let x = t + 1 in let y = x in let x = y + 1 in x) Output: 2