axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Axisp news


From: Martin Rubey
Subject: Re: [Axiom-developer] Axisp news
Date: 26 Jun 2007 12:20:13 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Dear Stephen,

many thanks for your detailed answer.  I must admit however, that I dislike
your idea writing

   D(P : Polynomial (R : Ring)) : ... == ...

for

   D(R : Ring, P : Polynomial R) : ... == ...

Isn't this just syntactic sugar?  My feeling (!) is that this will pose more
questions than answers.  Enforcing case sensitivity on values, domains and
categories also does not look very appealing to me, sorry.

In any case, I'd like to point you again to Christian Aistleitner, who seems to
have thought a lot about issues about Aldor semantics.

To look at OBJ is probably a good idea, though.

> Another shortcoming relates to `first class types'.  One can generate a new
> type at run time, but there is no elegant mechanism in place to recover the
> exact type.  Consider:
> 
>           mkMod(n : Integer) : IntegerMod( ? ) ==
>                                    IntegerMod(compute(n))

I'm not absolutely sure what you mean here, since IntegerMod(compute(n)) is
certainly not of type IntegerMod( ? ), no matter what the ? will be.

Note that a type is allowed to export its "parameters",
RectangularMatrixCategory does that.

> In addition, IIRC (its been a while since I played with aldor), there
> are real problems with how constants are treated.  In short, they are
> not really constants.  I remeber seeing code such as:
> 
>         add!(r: %, s: %, t: %) : % == 
>                  if one? % or zero? % then s + t else ...

I could not find code like that -- apart from the typo, you probably meant

         add!(r: %, s: %, t: %) : % == 
                  if one? r or zero? r then s + t else ...

> To work around the fact that the destructive add would modify the constants
> `0' or `1', leading to predictable surprises.  The imperative aspect of the
> language needs to be more carefully considered, IMHO, especially w.r.t the
> semantics of a types parametrized over (possibly mutable) values.

Yes, constants may contain mutable data.  But that's just as in other
languages.  It is true that you can say

l: List Integer == [1,2,3];
l.1 := 4;

but in my opinion, you are not really modifying l, but rather l.1, and that's a
different story.

> > * certain difficulties transforming Tuples
> 
> I assume your talking about the issues raised in the article I mentioned
> above?

possibly, but Ralf knows better.  Maybe you want to join our discussion on how
to implement multisort species in Aldor?  There, we are pushing the limits of
Aldor, I guess.  Also, the parser and domain generator I wrote shows some
features one may want to have.


Martin





reply via email to

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