axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: SPAD and Aldor again


From: Peter Broadbery
Subject: Re: [Axiom-developer] Re: SPAD and Aldor again
Date: Tue, 21 Nov 2006 20:46:14 +0000

I was going to write a fairly long flame as a reply.  I'll just state
that the aldor compiler is actually  better structured than most 200K+
line pieces of code I've had to deal with.  There are one or two other
statements I'd respectfully disagree with, but I can't be bothered.

The optimiser bugs are painful, and I wish they would be dealt with.
Hell, I'd give it a shot if the code was available.  (or remove the
optimisations, and fix the bits that require optimisation, one or the
other...). 

Naturally, the language isn't to everybody's taste, but does seem to
express a significant number of data structures and algorithms in a form
that people find attractive and useful. 

Dependent types actually require very little in the way of type checking
at runtime - since to the underlying interpreter, everything has more or
less the same type - the compiler does all the complex checking.  The
expensive bit (in terms of code size) is conditionals and parameterised
types, and even there, the time overhead is small if the code does
anything significant with a fixed set of types.  There is nothing here
that isn't done by java, except that types are created by things that
look like function calls rather than comparisons.

To get into some ideas where SPAD or aldor can be improved:

Conditional exports seem to be necessary with parameterised types (it's
a fair point that overloading 'if' is evil, I'd like to see some
alternatives though).

A syntax for naming type constructors in function calls, so

GraphCat(T: HashType): HashType == ...
GraphAlgorithms(T: HashType, G: (T: HashType) -> GraphCategory T) == {
   connectedComponents: G T -> Set Set T;
   connectedGraph: G T -> G Set T;
}       

was more akin to
GraphAlgorithms(BG: (G T == GraphCat(HashType)), X: S T == SetCat(HashType))
   connectedComponents: BG -> S S T;
   connectedGraph: BG-> G G T;
}

So we are not forced to use 'Set'. Unfortunately I can't suggest a nice
looking yet consistent syntax. 

Rep and Per are good for many things, but it might be worth adding a
shorthand for 'my representation is just a record'.  Don't think of Rep
as an instance variable - it's a mapping between your type and an
underlying one.  That said, a default representation of Rep + Record
might be an interesting idea.


Peter







reply via email to

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