axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Aldor-l] [Axiom-developer] "has" and "with" (was curious algebrafai


From: Weiss, Juergen
Subject: RE: [Aldor-l] [Axiom-developer] "has" and "with" (was curious algebrafailure)
Date: Mon, 13 Aug 2007 17:27:04 +0200

I don't think that the compiler automatically applies the
coerce functions. Haven't checked to substantiate that
claim though.

Regards

Juergen Weiss

Juergen Weiss     | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
address@hidden| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407
 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden
>  On Behalf Of Ralf Hemmecke
> Sent: Monday, August 13, 2007 4:55 PM
> To: Gabriel Dos Reis
> Cc: address@hidden
> Subject: Re: [Aldor-l] [Axiom-developer] "has" and "with" 
> (was curious algebrafailure)
> 
> > The Spad compiler tries to treat category constructors, domain
> > constructors, package constructors, and function calls as 
> uniformly as
> > possible.  What I mean by that is that it applies the principle:
> > 
> >    When calling a function, collect candidates, filter them by
> >    applying the criteria that the arguments match the 
> parameter types.
> >    And select the best match if possible.
> 
> Oh, I hope that will change. The compiler should *never* have 
> a choice 
> left. Either after filtering there remains *exactly* one 
> possibility or 
> the compiler should complain.
> 
> > And that irrespective of whether the arguments are value expressions
> > or domain expressions.
> 
> > By "matching" here, I don't necessarily mean only `pattern 
> matching'.
> > Rather I mean `coercible'.  For example an expression of 
> type Integer
> > is coercible to Float because Float exports the following function
> > 
> >      coerce : Integer -> % 
> 
> That is exactly what Aldor does *not* do. It never applies 
> "coerce" if 
> one doesn't explicitly call for it. At the moment I find Aldor much 
> better in this respect. You should consider that some people might 
> implement a function that is not a nice "coerce" (although their 
> function carries this name).
> 
> Just suppose in the context where there is an integer that must be 
> coerced into something of MyDomain. I have written a possible 
> coercion 
> function in MyDomain that could be used for that task by the SPAD 
> compiler. But what I actually want was to call another 
> function. I had 
> just forgotten to write it into the source code. Then the compiler 
> happily inserts "coerce" and I don't see (don't get a 
> warning) that my 
> code is actually not as I wanted it to be. Yes it means more 
> typing, but 
> that is not a big burden if you see from the code what is happening.
> 
> Remember that in Axiom you can coerce anything to anything. 
> Just write a 
> function "coerce" with the corresponding types. So if I add a function
> 
>    coerce: Float -> Integer
> 
> probably a lot will go wrong and nobody will easily find the error if 
> the compiler does not give an error or at least warn.
> 
> I understand that the idea of automatic coercion is a good one at an 
> interactive level, but at the library I don't want to have it.
> 
> I am quite interested how other people feel about automatic coercion.
> (You should read Doye's thesis before you answer.
> http://portal.axiom-developer.org/refs/articles/doye-aldor-phd.pdf)
> 
> If these coercion paths are always unique then I am certainly for it, 
> but I somehow think that there is still a lot of research to 
> be done on it.
> 
> Ralf
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]