This is a list of problems that can be addressed to some extent by creating a new generators-2 namespace.
For each problem, there is a proposed solution with and without adding a new namespace.
Under every "WITHOUT Reboot" section, there is an implicit alternative to do nothing.
- Many generators have confusing names
- E.g., monadic names (return, fmap, bind), and others (elements, hash-map, one-of)
- WITH Reboot
- Pick better names
- WITHOUT Reboot
- Add aliases and mark the old names as deprecated
- Difference between a var referring to a generator vs a function that returns a generator can be error-prone for users, and leads to a duplication of names like
gen/doubleandgen/double*to allow for options to be passed- WITH Reboot
- Make every var a function that returns a generator
- WITHOUT Reboot
- Add an IGenerator protocol so that vars like
gen/doublecan be backwards-compatibly changed to functions that can act as generators in a deprecated manner (with optional warnings?)
- Add an IGenerator protocol so that vars like
- WITH Reboot
- Options API is inconsistent
- Some functions take an options map, others have similar options as positional args
- WITH Reboot
- every generator should take an options map, as an optional argument after all of the required args
- WITHOUT Reboot
- Modify signatures with backwards compatible support for the deprecated signatures
- Built-in composite generators like
gen/anydo not allow customizing the underlying base generators – most notably, you cannot askgen/anyto avoid generating NaNs (but with more options on other base generators this would be a more general problem)- WITH Reboot
- These generators would be functions and could therefore pass options down to their constituent generators
- WITHOUT Reboot
- Do the "WITHOUT Reboot" steps in the previous two points, and then do the same thing we would do in a reboot
- WITH Reboot
- Integer generators need overhauling
- There are a lot and some are misleadingly named. They could all be collapsed into a single generator with rich options for specifying the distribution
- WITH Reboot
- Make a single
gen2/integer
- Make a single
- WITHOUT Reboot
- Make
gen2/integerand deprecate all the others
- Make
gen/bindhas confusing argument order- Every other combinator takes the generator as its last argument
- WITHOUT Reboot
- Accept args in either order? This could be ambiguous if we also convert everything to functions but allow the functions to be used as generators
- WITH Reboot
- Change the arg order in the new function
- String generators are pretty basic
- the non-ascii generators use a fixed small range of non-ASCII unicode characters
- WITHOUT Reboot
- Add a new string generator that takes options for distribution, deprecate all the old ones
- WITH Reboot
- Add a new string generator that takes options
- Collection sizing is bad
- Collection generations naïvely result in the expected size of the generated value being N times larger than the expected size from the element generator
- A better situation would perhaps involve
- Collection generators that reduce the `size` used for their elements according to some rule, perhaps based on the expected size of the collection
- Some sort of in-place accounting for how much stuff is being generated as it goes, so that the size can be suppressed further if the value is getting too big, mitigating the risk of the largest 0.001% of values being OOMly large
- Standard options for users to have more control of the above behavior
- WITHOUT Reboot
- Change built-in generators in place to effect the above solution (should this be considered a breaking change, if old calls still work but perhaps generate different distributions?)
- Create new collection generators according to the above solution and deprecate the old ones
- WITH Reboot
- New collection generators according to the above solution
Labels:
