On 2014-07-23 18:36, Yotam Barnoy wrote:I humbly suggest trying to use it before proposing aesthetic changes.
Very nice.
I've never used any of the deriving extensions before, but I have an
aesthetic suggestions.
I believe this is best left to the upcoming implicits, which will
Would it perhaps make sense to generate a
module per derived type? For example a type t would generate a module
T_ (the underscore or any other suffix would reduce mixups with
pre-existing modules). You could then use code such as
'if T_.(a = b && b = c) ...'
or 'T_.show x ...'
which allows you to keep the infix notation for = which is important
IMO.
You could even generate T_ as having internal Eq, Ord, and Show
modules (as requested by the user), which would be included in the T_
module. This would allow you to easily pass them as first class
modules to functions accepting Eq, Ord or Show signatures.
hopefully be merged soon.
I have based the current design on existing patterns across OCaml
ecosystem; I don't want to change the way people structure their
modules, I want to reduce the amount of boilerplate to write.