Martin Rubey wrote: > My personal preference is: > > * no automatic coercion in the compiler
In principle, I agree with this. The source of library code should be unambiguous (in addition to well-documented). In practice, it would be nice if there is some help, such as spitting out possible coercion paths when explicit coercions (there being no other type under this policy) are not specified or ambiguous due to identical signatures (hence, a similar help should be given for package calls). My Spad experience has been that, conservatively estimating, over 70% of coding time is on coercions and perhaps 10% of time to find and specify the package calls. So any type of assistance, whether you call it automatic or not, will be much appreciated. > * automatic coercion (as intelligent as possible, possibly even several steps, > i.e., assuming that all coercion paths yield the same result, although this > will sometimes not be true in reality) in the interpreter I don't believe there should be two different strategies (or standards if you will), one for compiler and one for interpreter. If people find automatic coercion in the interpreter convenient and useful say 90% of the time, that saves time in developing code. (There are plenty of empirical evidence: the popularity of Maple and Mathematica in casual as well as serious computations.) Having a different strategy is the cause of all the "pain" when a fully tested interpreter code is turned into Spad because it would not be accepted by the compiler (that is where the over 70% of time of code development is spent). I would prefer the compiler also "preprocesses" source code, perhaps reporting (much like ")set mess bot on" in the Axiom interpreter) its choices and ideally, in a supporting editor, allows the programmer to decide to accept or not. The Axiom language should be one, not two. We learn through repetitions. This will significantly lower the slopes of the learning curve. For diehard users, there is no prohibition for them to explicitly call coercions or packages. The problem of different paths of coercions between two given domains has to be dealt with separately, from a general policy to enforce commutativity of diagrams (in the sense of Category Theory). It is not just a problem on coercion maps. A database of commutative diagrams need to be maintained. It is a very important part of constructive algebra (which is partly based on algorithms for universal objects). > When writing library code, the extra pain to write down the coercion is really > worth the effort. The combinat experience was much more pleasant than the > Guess experience, in this particular point. No, "pain" should not be the norm (and definitely, not "extra pain"), but rather the metric. Intuitively, positive experience can only be assured when there is less pain. > Using the Aldor interpreter however is a pain for me. For me, translating Spad code accepted by the Axiom interpreter into Spad code accepted by the compiler is a pain. Either require explicit coercions and calls in both the compiler and interpreter, or provide the SAME verifiable/selectable assistance in both cases. William _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer