Re: [Axiom-developer] Unions in Spad

[Stephen Wilson]

William Sit <address@hidden> writes:
> In summary, we need:
> 
> 
> (1) make a list or set of domains from SetCategory (or any category) a legal 
> construction
> (2) SetAsDomain to convert a list or set of domains (or elements, or maps, 
> perhaps or
> categories) as a domain of SetCategory
> (3) Record to accept dependent types, such as [i: I, x:g(i)]
> (4) maps such as g: I -> SetAsDomain([Integer, String]) should be first class 
> objects and
> used as parameters, and definable in the Interpreter.

Ok. I believe that the IndexedUnion implementation might need to wait
until some basic support can be made available in the compiler.

I believe that 1) is realistic as a near-term extension, at least
within Spad code.  I do not know a lot about the interpreter
implementation so am unsure how much work is involved there.

Given 1), does 2) not follow by defining SetAsDomain as a domain constructor?

However, 3) and 4) might require a large amount of work.  This is
something I am more than willing to do.  However, a few notes:

Once we have a working Axiom atop GCL-2.7.0, this opens up a new world
for developers (an ANSI lisp).   I am trying to get that working with
the hopes that I can exploit the new features in an attempt to
reimplemented the compiler.  This is a huge task, of course, but I think
it is attainable.

The rewrite can attempt to accommodate the needs and issues raised by
yourself and others.  On an item by item basis, this might prove to be
easier in the context of a rewrite than trying to shoehorn more
features into the existing system, and to do so in a way such that
little or nothing else breaks.


What Im trying to decide here is how best I can focus my efforts.  I
am reluctant to invest a huge amount of time in extending a system I
have every intention of rewriting!  I realize that this is quite
selfish of me, for putting my own interests and goals first.  I do so
only because I think the returns are greater in the long run, compared
to expanding the current implementation over the course of the next
thirty years.


Take care,
Steve