Steps to propose a new primop in GHC

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. Thanks, Mitsutoshi

I forgot to mention that I have prototype implementation:
* https://github.com/maoe/ghc/tree/traceEventBinary
*
https://github.com/maoe/ghc-trace-events/blob/feature/traceEventBinary/src/D...
Some details still need to be sorted out though.
Regards,
Mitsutoshi
2018年5月28日(月) 16:23 Mitsutoshi Aoe
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.
Thanks, Mitsutoshi

Mitsutoshi Aoe
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

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.
Regards,
Mitsutoshi
2018年5月30日 5:33 +0900、Ben Gamari
Mitsutoshi Aoe
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

Mitsutoshi Aoe
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.
Absolutely. I'm looking forward to seeing 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.
Yes, of course. Silly me. Cheers, - Ben

Hi Ben,
I just submitted a patch (with slightly different names from the earlier
message) for this change at h
Mitsutoshi Aoe
writes: 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.
Absolutely. I'm looking forward to seeing 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.
Yes, of course. Silly me.
Cheers,
- Ben
participants (2)
-
Ben Gamari
-
Mitsutoshi Aoe