You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 18, 2021. It is now read-only.
In PR #259 it was noted that GConName/CommandNames could be simplified using generic-sop. In PR #242 another dependency on generic-data is introduced in order to get generic bounded and enum instances. Perhaps generic-sop or generic-data can be used for both, and also the Rank2 stuff.
We should consider how much the refactor would simplify the library (if at all considering the overhead of, for example, learning generic-sop) vs how annoying it would be for the users of the library (yet another dependency, api change, extension and deriving instance, etc)...
The text was updated successfully, but these errors were encountered:
I also put gconName in generic-data. The plural version gconNames can be obtained as map conIdToString (conIdEnum @MyType); I wouldn't mind adding it as a shorthand too.
I'm not sure what to do about Rank2.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In PR #259 it was noted that
GConName
/CommandNames
could be simplified usinggeneric-sop
. In PR #242 another dependency ongeneric-data
is introduced in order to get generic bounded and enum instances. Perhapsgeneric-sop
orgeneric-data
can be used for both, and also theRank2
stuff.We should consider how much the refactor would simplify the library (if at all considering the overhead of, for example, learning
generic-sop
) vs how annoying it would be for the users of the library (yet another dependency, api change, extension and deriving instance, etc)...The text was updated successfully, but these errors were encountered: