|Version 4 (modified by john@…, 10 years ago) (diff)|
Ambiguous Types, and Defaults for Overloaded Numeric Operations in the Haskell 98 Report.
- Defaults are limited to certain classes. A tool like Hat, which transforms Haskell source, cannot transform the defaults, because there is no way make defaults apply to the transformed classes rather than the original ones.
- Report specification when it comes to defaulting is impossible to implement when general recursive modules are allowed.
- It should be specified that a group of mutually recursive modules must have exactly the same defaulting.
- Perhaps require a default clause to name the class being defaulted over, as well as the type to choose.
- A default clause applies only within the module containing the declaration. Defaults can be neither
exported nor imported. Does anyone wish to propose import/export of defaults?
- For import/export: easier to propagate user-defined class defaults throughout a project
- Against import/export: a change in the imports of a module might silently change behavior
- A compromise might be to allow defaults which will be inherited to be specified only in the module that defines a class, but groups of mutually recursive modules may override defaulting locally. this will avoid the import changing behavior problem and allow some sort of inheritence of defaults.
Allow defaulting clauses of the following form
default <classname> (type1,type2,type3,...)
The defaulting rule will simply choose the first unambiguous type that satisfies all the constrained classes listed in the default decls.
Classes without defaults will have the equivalent of an empty list of types, so defaulting will not occur.
It is important to specify "unambiguous", because in the case of
default A (Int, String, ()) default B (String, Int, ())
the only valid default for a type in both classes A and B should be (). This avoids making an arbitrary choice based on textual ordering of the default declaration clauses.
- very useful in interactive interpreter
- less ad hoc than current method
- overcomes the Hat transformation problem
- can not exactly replicate behavior of existing defaulting mechanism, but can come close.
- might hide errors, an optional warning on defaulting should be possible.