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

[Richard Eisenberg]

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 <iavor.diatchki at gmail.com> 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 <ghc-steering-committee at haskell.org> 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 <arnaud.spiwack at tweag.io>
>> Sent: 06 November 2019 09:31
>> To: Simon Peyton Jones <simonpj at microsoft.com>
>> Cc: Richard Eisenberg <rae at richarde.dev>; ghc-steering-committee <ghc-steering-committee at haskell.org>
>> 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 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