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 algebra fa


From: Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-developer] "has" and "with" (was curious algebra failure)
Date: Tue, 14 Aug 2007 06:00:05 -0500 (CDT)

On Tue, 14 Aug 2007, Ralf Hemmecke wrote:

| > | > 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).
| > 
| > I don't think there is anything we can do about that.  We can't police
| > people that name coerce a function that does pretend.  Sometimes that is
| > bad, sometimes that is good.
| 
| I've stated my concerns. What else can I do?
| 
| I was happy that automatic coercion went away when I switched from Axiom to
| Aldor. I don't want to go back.

Notice that if coercions are required to be explicitly spelled out,
people writing non-"nice" coerces will still get away.  

I'm not saying all coercions are good.

However, I'm not at all convinced that requiring everything single
coercion to be written explicitly is either a necessary or a sufficien
condition for correctness.  This debate is not new to me -- remember I come
from C++ world?  I'm familiar with most of the arguments you've developed.

Notice also that in Aldor, I believe you still have coercions between
types.

| Yet another reason against auto coercion.
| There might be a situation when coerce: A->B is needed and none is in scope
| but there were coercions available such that A->X->B or A->Y->B.

If both are in scope, I would say the compiler should report ambiguity.
Furthermore, in a "sane" environment, they should all be semantically
equivalent.  But, there is nothing we can do for that.

| We all want that both compositions yield the same result. Now let's suppose we
| enforce that (at least in the documentation). There is still the issue of
| efficiency. The path over X might be more costly than the path over Y. Which
| one does the compiler choose and how can you see that from the source code?

As I said above, this is a case where given those 'syntactic' equal choicese
(syntactic, because the compiler has no idea of the runtime properties), the
compiler should report ambiguity.

| I like this extra bit of redundancy in the code. It is good for people who are
| not the authors. (And it probably makes compilation faster.)

Are you sure the coercion step is a performance bottleneck for real
applications?

-- Gaby




reply via email to

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