Re: [ghc-steering-committee] #195 recommendation: accept

Those answers are helpful, yes, but I would want them incorporated in the proposal. And does Matt agree with these answers? Thanks for writing that up! Richard

On Nov 6, 2019, at 4:33 PM, Iavor Diatchki wrote:

Hello,

I thought my comment on GitHub answered Simon's questions, but Matt should indeed update the proposal to make it explicit. For the record here is how I think they should be answered:

* Is the data constructor Code visible to clients? Can they look inside the abstraction? - I think we should have a way to convert from `Code a` of a type `Q (TExp a)`. `fromCode :: Code a -> Q (TExp a)` - I don't think it matters very much if this is done with a function like that or by exposing thew newtype constructor. - My preference would be to keep `Code` abstract and have the function.

* unsafeQ lets you turn a Q (TExp a) into a Code a. But how can you get a Q (TExp a) in the first place? - I would imagine that you'd mostly get it out of `Code` using `fromCode`. - Another way would be to make it unsafely using the `TExp` constructor directly.

* Can you/should you be able to get a Q (TExp a) from a Code a? - Yes: it allows splicing typed code in untyped contexts which seems useful.

* The text says unsafeQ is added in order to perform unsafe Q actions inside of Code. So I was expecting something like unsafeAddQ :: Q () -> Code a -> Code a unsafeAddQThen :: Q a -> (a -> Code b) -> Code b

These can be defined using `fromCode` and `unsafeQ`. If you think they might be useful, we could probably add them to the TH modules. unsafeAddQ q c = unsafeQ (q >> fromCode c) unsafeAddQThen q k = unsafeQ (q >>= fromCode . k)

What do others think? Richard, you also had some questions but I am not sure what they are, does this help?

-Iavor

On Wed, Nov 6, 2019 at 1:35 AM Simon Peyton Jones via ghc-steering-committee wrote:

...

I'm rather curious of what made my email sound like I was suggesting immediate acceptance,

I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.”

I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies.

Simon

From: Spiwack, Arnaud Sent: 06 November 2019 09:31 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept

I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better.

For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread.

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

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