As several people responded to what i call
instance-ruled type conversion proposal to Haskell,
i put the proposal and further explanations to
ftp.botik.ru:/pub/local/Mechveliani/typeConvProposal.txt
It started with
Recent Haskell ignores the possibility of the automatic type
conversion. Thus, 1 + 1%2 is ill-typed.
...
-------------------------------------------------------
Alastair Reid notes that 1 + 1%2 is well-typed.
Sorry, i have mistaken. And the compilers behave right.
-------------------------------------------------------
But let us forget now of this implicit fromInteger setting.
Proposed is the generic mechanism of the type convertion.
My last letter had better to start with
"
Recent Haskell almost ignores the possibility of the automatic type
conversion. Thus, declaring the polynomial constructor Pol,
the Num instance for it, and writing
x + y^2 :: Pol (Pol Int)
for the polynomial in y with coefficients - polynomials in x
(x :: Pol Int, y :: Pol (Pol Int))
we obtain an ill-typed expression.
While in practice, x is considered here as imbedded to
Pol (Pol Int), and the expression is presumed to be
x*y^0 + 1*y^2
"
And the proposal does not change.
D.Tweed <[EMAIL PROTECTED]> writes
>To add my 2c... I think the original proposal was a general scheme for
>defining `implicit coercions' via a multiparameter typeclass construction
>which is treated specially by the compiler, and numeric conversions were
>the particular motivating example.
Exactly.
And the feature has, probably, to deal with the overlapping instances.
Eric Blough <[EMAIL PROTECTED]> writes
>I think that Sergey is offering a proposal for numeric type coercion,
>such that (for example) for n :: Int and x :: Float, n*x will be well
>typed, without the need to write (fromInteger n)*x.
>...
The idea is *much more generic*.
This is the generalization of `asTypeOf`.
Consider the data constructors D1,D2... from many different "data"
declarations and the expression
(D1 2 'b') `asTypeOf` (D2 (D3 (D4 1) 'a'))
It does not necessarily deal with "numerics". And what might it mean?
The Proposal proposes to set (D1 2 'b') `cv` (D2 (D3 (D4 1) 'a'))
instead and understand this according to the instances of the standard
Convertible class with the cv operation.
The program may contain some instances of Convertible which relate
to D1,D2...
*If* it follows from these instances that Convertible s t
holds for the types s,t of expressions
e1 = D1 2 'b', e2 = D2 (D3 (D4 1) 'a'),
then cv e1 e2 converts e1 to the type of e2.
How it is converted?
According to the user-defined law of conversion, according to the
Convertible instances related to some of D1,D2...
For, one application judges that 'a' converts to (Char,Char)
as ('a','a'),
another, maybe, as ('b','b'),
and the third assumes that it is not convertible at all.
According to the Haskell semantics, the instances of Convertible for
some of D1,D2... *compose*, and the effect is that e1 may convert
to the type of e2 through the several levels of constructors.
This feature is of extreme importance in programming mathematics.
People, please, read the whole proposal.
The part (2) of proposal suggests certain change to the semantic.
Many of cv operators have to be set automatically, again, according
to the Convertible instances. This has to be the generalization for
the strategy according to which some existing compilers insert
`fromInteger'.
D.Tweed <[EMAIL PROTECTED]> writes
>I've no problems with this in principle but would like some way of
>ensuriing that, if I were using other people's code, I could ensure that
>all their implicit conversions are securely locked away in their modules
>only, even if constructors for which they are defined have been exported
>into my code. In particular, although it is sometimes a nuisance I prefer
>Haskell's complaints about mixing Ints, Floats, etc..., to C's automatic
>conversions which mean that trivial typos can completely corrupt numerical
>components of a program without any compiler warnings.
Yes. A bug farm. For example, the typo n + 1%2 instead of n%2 + 1%2
may lead to incorrect computation instead of the type error message.
But if the programmer decides to close this bug farm for some
constructor D, one simply does not declare `Convertible' for the things
related to D.
And do not worry of the Prelude constructors. We may exclude them
from discussion.
Suppose the program P. imports the application A., with the data
constructor, say, Pol a, and Pol is treated in A. as the subject of
`Convertible' instances. Then, of course, P. imports automatically the
way in which things are converted implicitly between any
b and Pol a.
The constructor is imported along with its declared conversion rules.
This is the consequence of the instance import in Haskell.
The possible way to relax this requirement: let {cvScope <e> }
mean that in the expression (or maybe, a program fragment) <e> the
types are converted implicitly, in other places they are not.
This will help a lot when the large formulas are evaluated in the
dialogue mode. Similarly, this will help in Main.hs, main = ...
in the batch-mode systems, where there are usually placed the
computations which in interactive systems are entered in the dialogue.
People could say that this is all for the *preprocessor*.
But writing such a preprocessor is as complex as writing the very
Haskell compiler. Right?
In particular, not only the arithmetic expressions have to transform.
Thus, in
f :: D1 Int -> D2 Int
f 0 = 0
f n = n+1
First `0' has to try to transform to
let z = 0::Int in `cv z (D1 z)',
second `0' to ... `cv z (D2 z)',
and `n+1' to `cv (n+1) (D2 z)'
- only the compiler has first to search for the neccessary
Convertible instances.
There remains other subtle issue, concerning that in my program the
values are converted between the algebraic domains, not simply types.
But let it so far be discussed for the types.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]
