> 3. I think it's quite important to use "<-" rather than "=".
> a) it means that the syntax is precisely that of list comprehensions
> b) there's an "=" in the definition already, as Andy points out:
> simplify (Plus e e') | let (Val 0) = s = s'
> | let (Val 0) = s' = s
> | otherwise = Plus s s'
> where
> s = simplify e
> s' = simplify e'
>
> now there are too many "=" signs to parse easily.
>
The proposal was to substitute qual for exp^0 in the syntax of guards,
implying that the use of let decllist in a guard is legal. If it is legal,
people will use it. I take it that "too many "=" signs to parse easily" refers
to a human reader, not to a machine. There is no ambiguity in the syntax.
> c) Furthermore, "let" can introduce multiple
> mutually-recursive bindings,
> and that leads to all the "which order to test" problems
> that I outlined earlier.
>
> Point (b) might even suggest disallowing the let form. Under my proposal
> I can write this:
>
> foo x | let y = x+1 = y+1
>
> It's a bit silly, because I can also use let or where in this
> situation, but it's not ambiguous so I don't see any particularly
> good reason to disallow it.
>
One can write ugly code in any language. The concrete syntax here is not
ideal, but the proposal is too good to lose simply because of that. The
problem is the old one that there are just not enough graphics to go round.
> CONCLUSION: "let" should be allowed, but should introduce multiple,
> mutually-recursive bindings. If any are pattern bindings then they
> are matched lazily, and failure to match is a program error. Exactly
> as for ordinary let/where bindings, and let bindings in list
> comprehensions.
>
Agreed.
--brian
