William Sit <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer