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

[Spiwack, Arnaud]

I am broadly supportive of this issue. I do find the `of` keyword rather
off-putting. But I could live with it.

Many variations are being mooted on the github thread, I don't really have
an opinion among all of these yet.

On Fri, Sep 4, 2020 at 6:04 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> 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
>>
> _______________________________________________
> 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/20200916/1f7bec32/attachment.html>