[ghc-steering-committee] Proposal #606: small syntax change around types in terms; recommendation: vote

[Arnaud Spiwack]

I keep going back and forth. But

I vote 1

On the grounds that:
- The extra parentheses would almost always be needed, 2 is probably an
unreasonable amount of syntactic noise
- We write `type Maybe a = …` not `type (Maybe a) = …`. So there's more
symmetry with the declaration in 1.

Yet, like Simon and Joachim, it took me a second to parse `f (type Maybe
Int)` correctly.

On Thu, 25 Jan 2024 at 07:14, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Maybe I'm misreading this, but this can potentially break existing code,
> can it not?
>
> On Thu, 25 Jan 2024 at 02:47, Richard Eisenberg <rae at richarde.dev> wrote:
>
>> Proposal #606 <https://github.com/ghc-proposals/ghc-proposals/pull/606> has
>> been submitted to the committee, by Vlad.
>>
>> This proposal makes a tiny change. Suppose we have `f :: forall (x ::
>> Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as
>> proposed) we can write `y = f (type Int -> Int) abs ...`. The `type`
>> keyword here is to signal that what comes is a type: it should be parsed as
>> a type and name-resolved as a type. This might matter if there is, say, a
>> constructor Int in scope. The proposal at hand is whether to accept the
>> above program or to require extra parentheses, thusly: `y = f (type (Int ->
>> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should
>> _not_ accept the former, without parentheses.)
>>
>> The motivation is to avoid surprising users. Normally when we have `word1
>> word2 -> word3`, word1 and word2 will associate more closely than the
>> arrow. Yet the first example has `type Int -> Int` where the arrow binds
>> more tightly. Because `type` is a keyword, this is no challenge to parse
>> and is not ambiguous -- it's just perhaps confusing to users.
>>
>> There was some debate in the proposal, but in my perusal, not a clear
>> indication toward any particular direction. The most rigorous statement I
>> could find is that the new syntax is a subset of the original, and so we
>> can easily reverse this decision later.
>>
>> I propose we vote on the matter. We have two choices:
>>
>> 1. Original syntax: allow `(type Int -> Int)` as an argument.
>> 2. Amended syntax: require `(type (Int -> Int))` as an argument.
>>
>> --------------------------------
>>
>> My vote: 1.
>>
>> There are many keywords in Haskell, and we are used to parsing these
>> differently. For example, if we have `f (do x <- blah ...)`, we know quite
>> well that the <- is within the `do`, not the other way around. Ditto
>> `case`: we don't require scrutinees to be parenthesized. I posit that the
>> strangeness some have felt around `(type Int -> Int)` is (understandable)
>> confusion in the face of novelty. But the `type` herald will not be novel
>> forever, and I think we'll enjoy having fewer parentheses in our code in
>> the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's
>> just skip the intermediate step and do 1 now.)
>>
>> I welcome your opinions and votes. It would be great to conclude this in
>> the next 2 weeks, by Feb 7.
>>
>> Thanks!
>> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/5dc5397f/attachment.html>