<div dir="ltr">I am not sure what problem we are solving, and I doubt this would lead to more readable Haskell, or more streamlined language definition.  So what's the gain?<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 7:57 AM Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com">trupill@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think that would work pretty well. In fact, the implementation of such a rule would allow us to also point beginners when they need parentheses in regular pattern matching!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg (<<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Thinking about disambiguating \case Just x -> x: There is no way that \of Just x -> ... can be correct, because Just requires an argument. Very happily, the renamer's behavior is unaffected: any variables introduced are still binding sites. So, I think we could probably detect a case like this in the type-checker and either reinterpret it correct or provide a very helpful error message.<div><br></div><div>So here's a concrete idea:</div><div><br></div><div>- Change the existing proposal to use \case instead of \of.</div><div>- Add a little magic to the type-checker, as specified below, to allow current usages of \case to be accepted.</div><div>- When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on by default).</div><div>- Remove the magic (and its warning) in a few releases.</div><div><br></div><div>The magic:</div><div>- The new construct allows many patterns before the -> where the old \case allowed only one.</div><div>- The type-checker detects when the first of these patterns is a solitary constructor, and when this constructor is not nullary.</div><div>- It then reconstructs the AST to move the remaining patterns as arguments of that first one. Because our AST tracks parens manually, the new AST will even print identically to the old one.</div><div><div><br></div><div>This magic is, well, magical, but it's well specified, backward compatible, and unambiguous.</div><div><br></div><div>What do we think?</div><div><br></div><div>Richard</div><div><br><blockquote type="cite"><div>On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" target="_blank">trupill@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>Hi all,</div><div>I agree with the sentiment. I think adding \of would be a nice way to clean up the language (in the same way that now StandaloneKindSignatures allow us to remove the weirder CUSKs), but unless we have some deprecation policy for extensions, this may confuse people more than help.</div><div><br></div><div>It's particularly bad that we cannot make this simply an extension of \case, due to the example pointed out in the thread: \case Just x -> x. Could we maybe think of some way to disambiguate those cases? I'm going to ask this in the thread too.</div><div><br></div><div>Regards,</div><div>Alejandro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.<br>
<br>
PR: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/302" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/302</a><br>
Proposal: <a href="https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md" rel="noreferrer" target="_blank">https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md</a><br>
Cale's recommendation: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014</a><br>
<br>
The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:<br>
<br>
mplus :: Maybe Int -> Maybe Int -> Maybe Int<br>
mplus = \of<br>
  Nothing _ -> Nothing<br>
  _ Nothing -> Nothing<br>
  (Just x) (Just y) -> Just (x + y)<br>
<br>
The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.<br>
<br>
I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.<br>
<br>
Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.<br>
<br>
Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>