Dear Haskell designers and users,
will you, please, analyze the following suggestion.
Let we call it the
extended type context attachement.
Example.
Consider the task of the determinant evaluation.
And let we *ignore* for this example the standard Prelude classes
Num, Fractional - this concerns the (+),(*),(/) treating.
det_generic :: AddMul a => Matrix a -> a
det_generic mM = expandByRow mM
where ...
det_field :: (AddMul a,Div a) => Matrix a -> a
det_field mM = gaussElimination mM
where ...
det_generic uses only (+) and (*) operations and is expensive.
det_field uses also (/) from (Div a) and is relatively cheap.
Note that the main issue is *not* an application specific.
Imagine any function that finds always the same thing, but in
different ways, depending on the presence/absence of certain
additional operation.
Further, it is very unnatural to call the matrix determinant with
different names (values). It should be named the same, say, `det'.
*Two* names really present a bad style. For the function name has
to reflect *what* it is computed and *not how* is computed.
We may also say that Haskell cannot understand this `det' as very
polymorphic.
Suggestion:
------------------------------------------------------------------
to make it possible to srcipt like this:
det :: AddMul a => Matrix a -> a
det mM = expandByRow mM where ...
det :: (AddMul a,Div a) => Matrix a -> a
det mM = gaussElimination mM
where ...
- and make the Haskell-1.? extension to understand that when a
type has the Div instance, it has to choose one definition,
otherwise, another one.
Probably, it is needed something like the disjoint union in the
type context: one declaration for det, but with the more
elaborated context construction.
------------------------------------------------------------------
I hope the Haskell designers can formulate this accurately and
preserving the implementability.
Thanks for the attention.
Sergey Mechveliani [EMAIL PROTECTED]
