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 08:29:48 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Stephen Wilson <address@hidden> writes:

> > Rather, PLEASE try to follow the Aldor User Guide.  Since Christian 
> > Aistleitner
> > wrote a parser for Aldor some time ago (in Aldor, sources being available 
> > from
> > himself, I believe), maybe you would like to get into contact with him.
> 
> Grammatically, Spad is fairly similar to Aldor, as you know.  I am actively
> thinking about Aldor features that I would like to integrate with the
> compiler down the road.  However, I am not commiting to cloning Aldor, as I
> feel there are shortcomings/difficulties.

I would really like to know what shortcomings you mean here.  I know of only
very few, and these are - in my opinion - really difficult questions:

* the problem of needing both AbelianMonoid as well as Monoid.

* certain difficulties transforming Tuples

> I would be happy to dicuss some of my plans for enriching the compiler with
> features familiar to Aldor if interested.

For a start (which will keep you busy the next few months I guess), there are
the following features SPAD needs badly.  Top priorities first:

* types and functions should become truly first class objects.  Currently, SPAD
  distinguishes between functions within a domain or package (eg., + or
  integrate) and domain constructors (like Fraction or Complex).  This
  distinction has to go away.  For example, I need to have the following
  signature allowed:

  Plus(
    F: (L: LabelType) -> CombinatorialSpecies L,
    G: (L: LabelType) -> CombinatorialSpecies L
  )(L: LabelType): CombinatorialSpecies(L) == add {...}

  I.e., F and G are functions that produce domains, and Plus(F, G) returns
  another such function.

  It goes without saying that I need full support for dependent types.

* Currently exports may be conditional, but only in a very narrow sense: only
  "has" and "is" statements are allowed in the condition.  This is too
  restrictive, as the example of the "Complex" constructor shows, where we want
  to export "Field" only if -1 is not a square root in the ground ring.

* It should be possible to define types recursively, as detailed in the Aldor
  User Guide

* Generators

> I would certainly like to encourage anyone to contribute their thoughts on
> what an `ideal' language should be.

I'm afraid that attempting to have an ideal language results in yet another
useless language in the end.  Too many people tried to do that, and only very
very few, very very gifted people succeeded.  Aldor is a pretty good language
for doing mathematics.

Martin





reply via email to

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