Repository navigation
Make a better story for split #97
Description
Activity
It looks like this was discussed in idontgetoutmuch#7 but for reasons I don't know was rejected there? Doesn't make sense to me.
FYI: I want to play with splittable generators specifically for incremental sorting of sequences (for
Data.Sequence).@treeowl Yes we did discuss this approach at lengths when working on random-1.2.0, but we decided not to tackle this problem for that version, since there was already tremendous amount of changes being introduced and we wanted to keep breakage to a minimum.
Here are my comments on your suggestion:
SplittableStatefulGenis not useful at all, because only pure PRNGs that have instance ofRandomGenare capable of splitting. For that reason I prefer to useRandomGenMclass instead and use the approach that is in the works in WIP: ImproveRandomGenMinterface: #93class RandomGen g => SplittableRandomGen g where:- I really don't like the name
SplittableRandomGen, I thinkSplittableGenwould be nicer - renaming
split->safeSplitwould introduce more work on the users side, it is better to migratesplitintoSplittableGenright away. - Introducing new class would mean that we must go through all PRNG libraries and create that instance, which is problematic, since majority of them are unmaintained.
- I really don't like the name
I thought about this issue quite a bit before, because I also share your dislike of partial functions, and I think I came up with slightly less invasive solution to this problem in #94, please let me know what you think.
I think we should look to
Data.Bitsfor inspiration here. Add a classsafeSplitis the same assplit, except it should only be defined for generators that are actually splittable.Question: can we improve efficiency or flexibility for any mutable generators by offering something like this?
I imagine this might be able to avoid some unnecessary copying in some cases.