[ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

[Simon Marlow]

I'm still in favour of Option (X), reject the proposal, for the same
reasons as before (copied below).

I think it was Cale who first proposed rejection:
https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075014

My previous email on this, although it talks about \of, applies equally to
\case and \cases:

> Cale's rationale chimes with me. A lot - I feel like I might have even
made the same point in previous threads on this. I think of the tradeoff
like this:

> * The lack of \of doesn't really hurt very much. In fact, arguably by
forcing the author to type some more characters and give something a name,
we get code that's clearer for the reader. (yes this is very subjective,
but syntax is).
> * The addition of \of *would* hurt new users of the language. Only a bit,
but every bit makes things worse, and things are already quite bad.

And I also came across this from Richard during the last thread:

> 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.


Cheers
Simon


On Tue, 15 Jun 2021 at 13:52, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> |  I’d like to reassing shepherding of this one.
>
> |
>
> |  It seems to be clear that we want “something like this”, there are many
> ways
>
> |  to skin the cat, so it comes down to opinion and what we need is a
> decision
>
> |  (or a call to votes). As with anything that’s possibly quite
> opinionated,
>
> |  it’s good to have an authorative voice, so in this case, Simon PJ.
>
> |
>
> |  Simon, can you either come up with a “all things considered, I think
> this
>
> |  variant is the (narrowly) the best” recommendation or, alternative, a
>
> |  “please vote on the following options” verdict?
>
>
>
> OK, to remind everyone
>
>    - Here is the proposal:
>    https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md
>    - Here is the discussion:
>    https://github.com/ghc-proposals/ghc-proposals/pull/302
>
>
>
> The basic idea is to extend to lambda all the facilities that you get with
> function definitions, especially multiple patterns and guards.   This seems
> clearly a good idea, whose only obstacle is syntactic.  There are no
> conceptual or specification challenges.  The only point at issue is that of
> concrete syntax.
>
>
>
> The proposal offers four possible syntactic options.  After reviewing, I
> propose to discard (2) and (3) leaving these alternatives
>
>
>
>    - *Option (1)    *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 }
>       - Lives alongside \case, but allows multiple patterns
>       - Other keywords are possible, but I think it must be a variant on
>       \case
>    - *Option (4)*   Same, but use \case as the keyword
>       - Incompatible with existing \case => extended transition period,
>       unhappy users
>       - \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens
>       forever, which in the common case of a one argument lambda see clunky.
>    - *Option (X).*  Reject the proposal.
>
>
>
> Personally I favour (1).   I’m relaxed about having multiple ways of
> saying the thing (think of let vs where), and I see no harm provided the
> two constructs look and behave the same.   I’ve decided I like \cases
> precisely because it’s the plural of \case, which is exactly what is going
> on.
>
> I think we’ll end up having to vote on this, which is fine when it’s a
> judgement call about syntax.   But first:
>
>    - *Are there any other alternatives you strongly want on the ballot?*
>
> I say “strongly” because I don’t want to open up a big new debate… we at
> the stage of trying to narrow options.
>
> Thanks
>
> Simon
> _______________________________________________
> 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/20210616/0c55bf6c/attachment.html>