axiom-math
[Top][All Lists]
Advanced

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

[Axiom-math] Re: [open-axiom-devel] [fricas-devel] generators, was: Re:


From: Martin Rubey
Subject: [Axiom-math] Re: [open-axiom-devel] [fricas-devel] generators, was: Re: iterators and cartesian product.
Date: 24 Oct 2007 14:37:42 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Gabriel Dos Reis <address@hidden> writes:

> On Wed, 24 Oct 2007, Martin Rubey wrote:
> 
> | The only thing I can do is to advertise the language design of Aldor...
> 
> I suspect that the compiler gurus already know Aldor's design choices.
> It may be that they don't want to replicate, or they would like to
> make slighly different choices...

Yes.  But I have the impression that so far the compiler gurus did not write
much mathematical code in Aldor or SPAD.  Of course, this does *not* mean that
I believe they wouldn't like to, or they would not know how to or some such.

All I'm saying is: I believe that I have a little experience to judge the
abilities and shortcomings of Aldor and SPAD when used as a tool for
implementing certain mathematics.(*)

I found, that I can live with the shortcomings of Aldor I encountered so far
(**), but I cannot really live with the shortcomings of SPAD.  Mostly, I miss
types being truly first class objects.

So far, I dislike most extensions to the language presented so far in the
mailing list, since what they provide, Aldor provides easily, or no real use
cases were given.  And, I should hurry to add, I personally also made proposals
that I find very stupid meanwhile.  Christian Aistleitner's insights helped a
lot here.

If you would like to make different choices, I'd very much like to know why.
If you have an idea why the Aldor (language, not compiler!)  designers didn't
take that choice, even better.



Martin


* I wrote the guessing package, which seems to work pretty well and outperforms
  all other similar packages so far.

  Together with Ralf, I wrote a pretty large library covering a lot of ground
  in combinatorial generation.

  During the workshop this year, we designed the basic structure for a package
  dealing with lambda rings, symmetric functions, and Hopf algebras.

** These would be, for example: 

   + the impossibility to have an AbelianMonoid be a Monoid
   + certain shortcomings of Tuples, as pointed out by Ralf
   + certain problems with dynamically creating new domains - although the
     current compiler allows it, only the language doesn't :-)





reply via email to

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