Add PrimMonad instance for CatchT

[treeowl]

exceptions defines a CatchT type that can be given a PrimMonad instance. Should we accept the dependency to add it?

[andrewthad]

I wouldn't like a dependency on exceptions. I would prefer that exceptions depend on primitive.

[chessai]

Agreed about the dependency thing. also the docs of CatchT mention that m should not unify with IO. I guess ST s might be fine?

[treeowl]

The problem is that primitive is not a terribly small dependency. Some people may be concerned about build time. I would probably rather move PrimMonad and PrimBase to the base library (in GHC.StateTransformers or something). The only tricky thing about that is that we'll have to convince Ross Paterson to put the necessary instances in transformers. An easier option would be to spin Control.Monad.Primitive off into its very own package, say prim-monad, that depends solely on base and is too small for (almost) anyone to worry about. There are a couple other pieces of this package that I think would be better off n their own packages: PrimUnlifted and Prim. Any time I see a package that could easily be split into several different ones, I tend to think it should be. This package, I believe, would split much more cleanly than some others that actually have been split.

[andrewthad]

I don't think of primitive as as big depedency. But, I could get behind the idea of moving PrimMonad, PrimBase, PrimUnlifted, and Prim into either some kind of primitive-class package or into base. I generally have a favorable view of bringing the most fundamental types and typeclasses into base (leaving functions in their own packages). PrimUnlifted certainly meets this standard, although it would be nice to remove the legacy methods that use unsafeCoerce# from it before enshrining it in base. I feel that the other three typeclasses are fundamental enough to go in base, but there's at least a little room for argument on those.

[treeowl]

I'd much rather not lump all the classes into one package, unless that is base. PrimMonad, PrimUnlifted, and Prim are three completely independent concepts which can be implemented completely independently. They're only tied together "a level up" by functions that use two of those.

[andrewthad]

That's fair. Since PrimUnlifted should not be moved until primitive's support for GHC 8.0 is dropped, it's probably worth checking on the libraries mailing list to see what people think about moving PrimBase and PrimMonad. But just the typeclasses. Not all their helper functions. That would solve the problem at hand.

[treeowl]

I can ask. Remember, though, that Paterson can effectively veto moving those two to base, so he must be convinced as well.

[treeowl]

The upgrade path is also non-trivial, so we'd need a plan.

[andrewthad]

The upgrade path I imagined was:

• Add a module named Control.Monad.Primitive.Class to base that just has the two typeclasses.
• In Control.Monad.Primitive, which still lives in primitive, use a little CPP to reexport those typeclasses if we are building against an newer base and define them if we are building against a newer base.

[cartazio]

we aren't adding dependencies to primitive, it doesn't help folks. And at some point folks in user space need to just write their own instances.

i'm actually working slowly on exploring splitting out the unlifted stuff into its own package. but thats also because i think the folks who are actually gonna use that are a specialized population.

realistically its gonna be years before we drop 8.0 i expect, i still try to make simpler packages i write work as far back as 7.0 or 7.6, and the meat and potatoes of primitive is stuff that should be super duper stable

[cartazio]

primmonad is def gonna stay in primitive,

[cartazio]

(i mean, if core libraries wants to adopt stuff, great, but base getting bigger actually hurts folk, eg, base recently got big enough that dwarf data gnerated by ghc at -g1 is now sooo much that you can't do a dwarf annotated build of base on mac OS X! anymore)

[treeowl]

@cartazio, can you consider my reasoning for splitting the package up rather than just rejecting out of hand? Users would only need to depend on primitive regardless, as it would provide all the modules from the sub-packages.

[cartazio]

i'm all for splitting out the unlifted and array kits into sub systems, so i aggree, just which is where,

i think more like primitive as the simple one, then -unlifted and -primarray and perhaps a -fancy overlay for experimental / exploratory stuff that needed be as long lived / stable

[treeowl]

@cartazio, I see. I had been operating on the assumption that we'd want as little breakage as possible. Moving things altogether out of primitive (so users have to add dependencies or switch to primitive-batteries or whatever) is major breakage. Breaking out pieces and making primitive depend on them avoids any breakage at all.

[cartazio]

very little code depends on unlifted and primarray, and theyre more complicated / less used by ecosystem, so i'm inclined to make it easier to workshop / iterate on those

[cartazio]

(so i'm not terribly concerned about user impact from moving those out, theyre both pretty recent)

[treeowl]

very little code depends on unlifted and primarray, and theyre more complicated / less used by ecosystem, so i'm inclined to make it easier to workshop / iterate on those

That may be, but Prim and the ByteArray and Addr operations it supports have been around for some time. Prim, however, has nothing at all to do with PrimMonad.

[cartazio]

i'm working through some of the implications of different parts,

im definitely comfortable moving unlifted tools out into its own thing, and def not 100% on the prim/byte array bits.

I've struggled to find any widely used/depended upon code in the wild that uses address. aside from the one gross spot in vector, have you seen any?

@treeowl it occurs to me, maybe we should create a "modern-pointer-experiments" package so we can workshop out some various modern style/improved pointer apis for haskell?

[andrewthad]

I make pretty heavy use of Addr in some of the software I work on for my job and in several unpublished libraries on my github. I am likely the main user of this API.

[cartazio]

Definitely! Yeah, I spoke with chessai about that and it seems like it’d be easy to fix on your side, or at least those apis would work just as correctly with say ‘Ptr a’, moral aesthetics / quality issues with say the storable pointer api (we should experiment with better pointer interfaces)

…

On Sun, Dec 2, 2018 at 3:16 PM Andrew Martin ***@***.***> wrote: I make pretty heavy use of Addr in some of the software I work on for my job and in several unpublished libraries on my github. I am likely the main user of this API. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#218 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwoVUlP8CyDvJbmPwrqgEhLiZn3Bdks5u1DUCgaJpZM4Y9O4A> .

[cartazio]

*aesthetic issues in the Address vs Ptr a vs current pointer apis could be made better aside On Sun, Dec 2, 2018 at 6:59 PM Carter Schonwald <carter.schonwald@gmail.com> wrote:

…

Definitely! Yeah, I spoke with chessai about that and it seems like it’d be easy to fix on your side, or at least those apis would work just as correctly with say ‘Ptr a’, moral aesthetics / quality issues with say the storable pointer api (we should experiment with better pointer interfaces) On Sun, Dec 2, 2018 at 3:16 PM Andrew Martin ***@***.***> wrote: > I make pretty heavy use of Addr in some of the software I work on for my > job and in several unpublished libraries on my github. I am likely the main > user of this API. > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#218 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAAQwoVUlP8CyDvJbmPwrqgEhLiZn3Bdks5u1DUCgaJpZM4Y9O4A> > . >

[chessai]

That is not a shared opinion. Also I think that this issue has derailed a bit. The splitting off of typeclasses into base or other packages should probably be its own issue. On Sun, Dec 2, 2018, 7:00 PM Carter Tazio Schonwald < notifications@github.com wrote:

…

*aesthetic issues in the Address vs Ptr a vs current pointer apis could be made better aside On Sun, Dec 2, 2018 at 6:59 PM Carter Schonwald < ***@***.***> wrote: > Definitely! > > Yeah, I spoke with chessai about that and it seems like it’d be easy to > fix on your side, or at least those apis would work just as correctly with > say ‘Ptr a’, moral aesthetics / quality issues with say the storable > pointer api (we should experiment with better pointer interfaces) > > > > On Sun, Dec 2, 2018 at 3:16 PM Andrew Martin ***@***.***> > wrote: > >> I make pretty heavy use of Addr in some of the software I work on for my >> job and in several unpublished libraries on my github. I am likely the main >> user of this API. >> >> — >> You are receiving this because you were mentioned. >> >> >> Reply to this email directly, view it on GitHub >> <#218 (comment) >, >> or mute the thread >> < https://github.com/notifications/unsubscribe-auth/AAAQwoVUlP8CyDvJbmPwrqgEhLiZn3Bdks5u1DUCgaJpZM4Y9O4A > >> . >> > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#218 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARyL66rtFEI_AYOQHAZ49FkROX4wuKhSks5u1GmagaJpZM4Y9O4A> .