Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Ryan Yates
ed more succinctly: gc perf dominates large heap / many core >>>>>>>>> computation in Haskell via sensitivity to allocation volume / mutation >>>>>>>>> volume (to ensure generational hypothesis stays valid), and providing >>>>>>>>

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Carter Schonwald
olume / mutation >>>>>>>> volume (to ensure generational hypothesis stays valid), and providing >>>>>>>> tools >>>>>>>> to incrementally reduce the pressure with local changes would be good. >>>>>>>> >>>

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Ryan Yates
;>>> machinery >>>>>>> that supports unboxed values. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 15, 2020 at 5:32 AM Andreas Klebinger < >>>>>>> klebinger.andr...@

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread David Feuer
020 at 5:32 AM Andreas Klebinger < >>>>>> klebinger.andr...@gmx.at> wrote: >>>>>> >>>>>>> From a implementors perspective my main questions would be: >>>>>>> >>>>>>> * How big is the benefit in practi

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Ryan Yates
ons would be: >>>>>> >>>>>> * How big is the benefit in practice? How many use cases are there? >>>>>> * How bad are the costs? (Runtime overhead, rts complexity, ...) >>>>>> >>>>>> The details of how this would be

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread David Feuer
questions would be: >>>>> >>>>> * How big is the benefit in practice? How many use cases are there? >>>>> * How bad are the costs? (Runtime overhead, rts complexity, ...) >>>>> >>>>> The details of how this would be expo

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Carter Schonwald
head, rts complexity, ...) >>>> >>>> The details of how this would be exposed to a user would are important. >>>> But if the costs are too high for the drawbacks then it becomes a moot >>>> point. >>>> >>>> >>>> David

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread David Feuer
osts are too high for the drawbacks then it becomes a moot >>> point. >>> >>> >>> David Feuer schrieb am 14.10.2020 um 22:21: >>> >>> Forwarded from Andrew Martin below. I think we want more than just Maybe >>> (more than one null), but the nestin

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread David Feuer
re too high for the drawbacks then it becomes a moot >> point. >> >> >> David Feuer schrieb am 14.10.2020 um 22:21: >> >> Forwarded from Andrew Martin below. I think we want more than just Maybe >> (more than one null), but the nesting I described is certainly

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Carter Schonwald
rom: Andrew Martin > Date: Wed, Oct 14, 2020, 4:14 PM > Subject: Re: Restricted sums in BoxedRep > To: David Feuer > > > You'll have to forward this to the ghc-devs list to share it with others > since I'm not currently subscribed to it, but I've had this s

Re: Fwd: Restricted sums in BoxedRep

2020-10-15 Thread Andreas Klebinger
- From: *Andrew Martin* mailto:andrew.thadd...@gmail.com>> Date: Wed, Oct 14, 2020, 4:14 PM Subject: Re: Restricted sums in BoxedRep To: David Feuer mailto:david.fe...@gmail.com>> You'll have to forward this to the ghc-devs list to share it with others since I'm not curr

Fwd: Restricted sums in BoxedRep

2020-10-14 Thread David Feuer
Forwarded from Andrew Martin below. I think we want more than just Maybe (more than one null), but the nesting I described is certainly more convenience than necessity. -- Forwarded message - From: Andrew Martin Date: Wed, Oct 14, 2020, 4:14 PM Subject: Re: Restricted sums in

Re: Restricted sums in BoxedRep

2020-10-14 Thread David Feuer
Yes, I think you're getting the gist. Pattern matching with one or two nulls is just an equality test or three. In practice, we'd want a fixed number of evenly spaced nulls, allowing jump table techniques to be used when there are more cases. We'd presumably have a hard limit for the number of null

Re: Restricted sums in BoxedRep

2020-10-14 Thread Spiwack, Arnaud
Ok, I believe get it now, Let's imagine (to take only the simplest case) that we have a `Nullable# a` type, such that `Nullable# a = (# (##) | a #)`. What would be the kind of `Nullable#`? I imagine that it would be something like `TYPE (BoxedRep Lifted) -> TYPE (BoxedRep Nullable)`. Then you wou

Re: Restricted sums in BoxedRep

2020-10-14 Thread David Feuer
I don't know your terminology, sorry. By "null" I'm referring to something distinguished, of which there can be more than one. These can be pointers to statically allocated objects if necessary, though pointers in an unused address range would probably be nicer. My goal is to be able to shove a com

Re: Restricted sums in BoxedRep

2020-10-14 Thread Spiwack, Arnaud
I don't imagine it would be hard for the GC to check that a pointer is null before following it. The argument may be, though, that it's too high a price to pay for the occasional use of a null pointer. (I must add that I have no opinion, or idea really, on this) On Wed, Oct 14, 2020 at 1:54 PM Seb

Re: Restricted sums in BoxedRep

2020-10-14 Thread Sebastian Graf
I believe Simon told me once that NULL pointers in places we assume BoxedRep things are not an option, because the GC assumes it is free to follow that pointer. It won't check if it's NULL or not. That's also the reason why we lower `LitRubbish` (which we use for absent BoxedRep literals) as `()` w

Re: Restricted sums in BoxedRep

2020-10-14 Thread Spiwack, Arnaud
I may have misunderstood, but my understanding is the following: - Since a is a boxed type, it can never be the null pointer - So I can use a null pointer unambiguously Let's call this null-pointer expanded type, `Nullable# a`, it is now a different sort than `a`, since it can have the null point

Restricted sums in BoxedRep

2020-10-13 Thread David Feuer
Null pointers are widely known to be a lousy language feature in general, but there are certain situations where they're *really* useful for compact representation. For example, we define newtype TMVar a = TMVar (TVar (Maybe a)) We don't, however, actually use the fact that (Maybe a) is lifte