Maybe you are right on this, and I just misunderstood let-guards. But with a non-recursive let, I would get a scope error instead of non-termination if I write let Just x | x > 0 = e ... which I definitely prefer. So, consider this aspect dropped from my proposal of non-recursive lets. On 10.07.2013 09:44, Dan Doel wrote:

On Wed, Jul 10, 2013 at 3:08 AM, Andreas Abel mailto:andreas.abel@ifi.lmu.de> wrote:

Another instance (cut-down) are let-guards like

let Just x | x > 0 = e in x

The "x > 0" is understood as an assertion here, documenting an invariant. However, Haskell reads this as

let Just x = case () of { () | x > 0 -> e } in x

leading to non-termination. A non-recursive version

let' Just x | x > 0 = e in x

could be interpreted as

case e of { Just x | x > 0 -> x }

instead, which is meaningful (in contrast to the current interpretation).

I still don't understand how this is supposed to work. It is a completely different interpretation of guarded definitions that can only apply to certain special cases.

Specifically, you have a let with one definition with one guard. This lets you permute the pieces into a case, because there is one of everything. But, if we instead have two guards, then we have two possible bodies of the definition, and only one body of the let. But, the case has only one discriminee (which comes from the definition body), and two branches (which are supposed to come from the let body). We have the wrong number of pieces to shuffle everything around.

The only general desugaring is the one in the report, but keeping the non-recursive let. This means that the x in the guard refers to an outer scope. But it is still equivalent to:

let' Just x = case x > 0 of True -> e in x

let' x = case (case x > 0 of True -> e) of ~(Just y) -> y in x

not:

case e of Just x | x > 0 -> x

case e of Just x -> case x > 0 of True -> x

-- 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 10.07.2013 10:00, Jon Fairbairn wrote:

Andreas Abel writes:

...

Proposal: add a non-recursive let to the Haskell language. In

let' p = e in e' do { ... let' p = e ... }

the variables of pattern p are then *not* in scope in e.

Reasons for adding a non-recursive let:

1. recursive-let is the source for many non-termination bugs.

-1 from me. I don’t see that having non-recursive let available will have much impact on the bugs. It just changes forgetting to use different variable names because of recursion (which is currently uniform throughout the language) to forgetting to use non recursive let instead of let.

Sorry, but I cannot change history. Ideally, "let" was non-recursive, and we had a "let rec" to indicate recursion. I certainly am not going to propose to make "let" non-recursive. I am not buying your argument. I think it is easier to retrain the brain to use "let'" instead of "let" by default, because writing keywords is a background activity (like walking) and does not need the attention that thinking of the right variable needs. (My brain does confuse names, but not articles like "der" and "das".) Also, I want shadowing because then there are less variants of variables around that I can confuse. Shadowing is a way to clean out the name space, to dispose of things you do not need anymore. Cheers, Andresa -- 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/