[ghc-steering-committee] Proposal #302: `\of`

[Iavor Diatchki]

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?


On Fri, Sep 4, 2020 at 7:57 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> 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!
>
> El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg (<rae at richarde.dev>)
> escribió:
>
>> 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.
>>
>> So here's a concrete idea:
>>
>> - Change the existing proposal to use \case instead of \of.
>> - Add a little magic to the type-checker, as specified below, to allow
>> current usages of \case to be accepted.
>> - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on
>> by default).
>> - Remove the magic (and its warning) in a few releases.
>>
>> The magic:
>> - The new construct allows many patterns before the -> where the old
>> \case allowed only one.
>> - The type-checker detects when the first of these patterns is a solitary
>> constructor, and when this constructor is not nullary.
>> - 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.
>>
>> This magic is, well, magical, but it's well specified, backward
>> compatible, and unambiguous.
>>
>> What do we think?
>>
>> Richard
>>
>> On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Hi all,
>> 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.
>>
>> 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.
>>
>> Regards,
>> Alejandro
>>
>> El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg (<rae at richarde.dev>)
>> escribió:
>>
>>> Hi all,
>>>
>>> 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.
>>>
>>> PR: https://github.com/ghc-proposals/ghc-proposals/pull/302
>>> Proposal:
>>> https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
>>> Cale's recommendation:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014
>>>
>>> The idea, in brief, is to introduce a new syntax (guarded behind
>>> -XMultiWayLambda) \of. Here is an example, which gives you the idea:
>>>
>>> mplus :: Maybe Int -> Maybe Int -> Maybe Int
>>> mplus = \of
>>>   Nothing _ -> Nothing
>>>   _ Nothing -> Nothing
>>>   (Just x) (Just y) -> Just (x + y)
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Richard
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200904/6dd97f62/attachment.html>