|Version 2 (modified by 11 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.
allow defaulting clauses of the following form
default <classname> (type1,type2,type3,...)
and the defaulting rule will take all class constraints and take the first unambiguous type that satisfies all the class constraints defaults.
classes without defaults will have the equivalant of an empty type list, 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 should be () to avoid any issues arrising from order of interpretation of defaults.
- very useful in interactive interpreter
- less ad hoc than current method.
- can not exactly replicate behavior of existing defaulting mechanism, but can come close.
- might hide errors, an optional warning on defaulting should be possible.
- importing a module might silently change behavior (this can be mitigated if we only allow default definitons in the same module as the class is defined, but that takes away the ability to redefine defaults)