[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: [Axiom-developer] Convert and Coerce

**From**: |
Ralf Hemmecke |

**Subject**: |
Re: [Axiom-developer] Convert and Coerce |

**Date**: |
Tue, 28 Mar 2006 12:33:43 +0200 |

**User-agent**: |
Thunderbird 1.5 (X11/20051201) |

First, there is a difference of Axiom and Aldor here.
If you say
a::B
than that means EXACTLY the same as
coerce(a)@B
Aldor treats :: as syntactic sugar and nothing more.
That also says if you have a function
convert: A -> B
but no function
coerce: A -> B
then the Aldor compiler will complain about a::B.

`Axiom is different (and I guess it is the same for SPAD) in that it
``translates a::B into either coerce(a)@B or convert(a)@B. (Hello Axiom
``gurus, correct me if I am wrong.)
`

`But anyway, inside library code NOTHING will be converted or coerced
``automatically.
`
On 03/28/2006 01:55 AM, Page, Bill wrote:

On Monday, March 27, 2006 6:36 PM Antoine Hersen wrote

I do not think that in general conversion implies any loss of
information. (I am not sure how to define "loss of information".)
But conversion is often a partial function i.e. only defined for
some members of the domain. For example:
2.0::Integer
If we only know
x:Float
it is not "safe" to write:
x::Integer
since
2.1::Integer
will fail. Such conversions will not be done automatically.

Actually, to be a bit more exact...
2.1::Integer
currently fails, but it only fails since there is not function
coerce: Float -> Integer
that does not fail for that input.
But read the thesis of Doye
http://portal.axiom-developer.org/forum/public/973207537422/view?searchterm=Doye
that says why you should not add a function definition like
coerce(f: Float): Integer == truncate f
Ralf