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
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-6660750... My previous email on this, although it talks about \of, applies equally to \case and \cases: 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.
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
And I also came across this from Richard during the last thread:
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
| 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-l... - 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee