Steps to propose a new primop in GHC

Mitsutoshi Aoe maoe at
Tue May 29 22:55:34 UTC 2018

Hi Ben,

Thanks for your reply. I take that at least for the GHC part I can submit the diff to phab and ask for review. I’ll do it.

> As far as adding a wrapper in `base`, I think we can just go ahead and
do it.

Note that the wrapper cannot live in base doe to the dependency on bytestring. I’m thinking to put it in my ghc-trace-events for now.


2018年5月30日 5:33 +0900、Ben Gamari <ben at>のメール:
> Mitsutoshi Aoe <maoe at> writes:
> > Hi devs,
> >
> > I'm thinking to add a primop in GHC but not sure how I should proceed. The
> > primop I have in mind is something like:
> >
> > traceEventBinary# :: Addr# -> Int# -> State# s -> State# s
> >
> > This function is similar to the existing traceEvent# but it takes a chunk
> > of bytes rather than a null-terminated string. It is useful to trace custom
> > user events (e.g. network packet arrival timestamps in an network
> > application) in eventlogs. At library level, it is supposed to be used like
> > the tracing functions in Debug.Trace but with ByteString argument:
> >
> > traceEventBinary :: ByteString -> a -> a
> > traceEventBinaryIO :: ByteString -> IO ()
> >
> > Note that this can't live in base because of the dependency on bytestring.
> >
> > So how should I proceed from here? Am I supposed to submit a GHC proposal
> > or should I ask on the libraries list? This is not a prominently visible
> > change in GHC. It rather affects only ghc-prim and no effects in base.
> >
> Hmm, that is a good question. I have also needed something like your
> traceEventBinary# in the past and I think adding the primop is rather
> non-controversial.
> As far as adding a wrapper in `base`, I think we can just go ahead and
> do it. `Debug.Trace` module isn't defined by the Haskell Report so I
> don't think there's a need to involve the CLC here.
> Cheers,
> - Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list