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

[Iavor Diatchki]

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