On Wed, 3 Apr 2024 at 22:08, Adam Gundry <adam@well-typed.com> wrote:

I also agree that we should accept. We need some name for the unit
unboxed tuple data constructor, and MkSolo# seems to fit with what we
currently have.

Simon's suggestion that we rethink the naming of the tuple type
constructors seems to be a separate question. I think it warrants a new
proposal/amendment if anyone feels strongly enough, rather than blocking
this proposal, especially given that the original proposal's type names
are already implemented.

Adam

On 14/03/2024 10:33, Matthías Páll Gissurarson wrote:
> I agree with the sentiment here, having Type0 and Type1 as the canonical
> names would have been preferable in the original proposal.
> However, this amendment doesn't touch on that: it only changes the
> constructor.
>
> We'd still want MkSolo# even if Solo was the synonym, due to the
> ambiguity described in the amendment.
> Renaming the canonical types would be a further, separate amendment to
> the original proposal.
>
> I believe we should accept the amendment, and consider a
> separate amendment later.
>
> On Tue, 12 Mar 2024 at 09:49, Simon Peyton Jones
> <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>> wrote:
>
> Unless I'm misreading, the proposal is only about the
> constructors' name. Which you don't propose to change, do you?
>
>
> Yes. I was questioning the proposal itself rather than the amendment.
>
> S
>
> On Tue, 12 Mar 2024 at 09:43, Arnaud Spiwack
> <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
>
> Unless I'm misreading, the proposal is only about the
> constructors' name. Which you don't propose to change, do you?
>
> (that being said, I think I agree with your comment that the
> name of the type ought to have been `Tuple1`, it'd make more sense)
>
> On Tue, 12 Mar 2024 at 10:38, Simon Peyton Jones
> <simon.peytonjones@gmail.com
> <mailto:simon.peytonjones@gmail.com>> wrote:
>
> Well this proposal deepens the commitment to an exception
> for Solo and Solo#. But I'm not really objecting, just asking.
>
> Simon
>
> On Tue, 12 Mar 2024 at 09:34, Arnaud Spiwack
> <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>>
> wrote:
>
> In favour.
>
> Simon: I don't think your objection pertains to this
> particular proposal amendment, does it? Rather it's a
> further change to the original proposal that you'd like
> to see.
>
> On Mon, 11 Mar 2024 at 11:48, Simon Peyton Jones
> <simon.peytonjones@gmail.com
> <mailto:simon.peytonjones@gmail.com>> wrote:
>
> Thanks Matthias
>
> I'm generally supportive, but please see my comment
> exploring a minor alternative
> <https://github.com/ghc-proposals/ghc-proposals/pull/638#issuecomment-1988147639>.
>
> Simon
>
> On Sat, 9 Mar 2024 at 00:12, Matthías Páll
> Gissurarson <mpg@mpg.is <mailto:mpg@mpg.is>> wrote:
>
> Greetings committee!
>
> In
> [proposal #638](https://github.com/ghc-proposals/ghc-proposals/pull/638 <https://github.com/ghc-proposals/ghc-proposals/pull/638>),
> @int-index proposes that we introduce a prefix
> form of MkSolo#, and apparent oversight in
> proposal #475 [Non-punning list and tuple
> syntax](https://github.com/ghc-proposals/ghc-proposals/pull/475 <https://github.com/ghc-proposals/ghc-proposals/pull/475>).
>
> Previously, you would write `(# a #)` to
> construct a `Solo# a`.
> But the question is: what would be the prefix
> form of this constructor?
> It can't be `(# #)`, because this is already
> defined as a constructor of `Unit#`!
>
> This amendment proposes the `MkSolo#`
> constructor, having us write `MkSolo# a` for the
> prefix form. The discussion seems unanimous,
> after care was taken to clarify that a fully
> applied `MkSolo# a` would still be pretty
> printed as `(# a #)`, avoiding programmer confusion.
>
> It seems quite straightforward to me, so:
>
> I recommend accepting this amendment to #475.
>
>
> --
> -- Matthías Páll Gissurarson <http://mpg.is/>

--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee