Martin Rubey <[EMAIL PROTECTED]> writes: [...]
| > Finally, mapping of Spad types to Lisp types is "interesting". For example, | > you may think that Spad List corresponds to Lisp list. But in OutputForm we | > have | > | > Rep := List $ | | Yes, I stumbled over that one some time ago, too. I think it's a bug. It | should probably be something like | | Rep := Union(String, Symbol, List $) Spad Union is not C union, so if you do the above expect to break just about everything, and have a very interesting bootstrapping journey. A long time ago, `OutputForm' tend to be called `Expression', e.g. equivalent to SExpression, until the difference was fully realized. If you browse the Spad compiler source code, you should still find vestiges of that. I must confess I don't know to what extent your plan diverges from or converge to my plan -- a year ago -- to have a virtual machine for Spad (my slides are still on the web). But, it is interesting that I saw all those problems you're discussing and concluded that it was time to abandon Lisp as the virtual machine one compiles Spad to. It is believed, to some degree that symbolic computation must be based on Lisp. I suspect that belief confuses specification and implementation. We don't need Lisp. In fact we use only a very tiny subset of Lisp. Also see the published work of Arthur Norman on that topic (CCL). -- Gaby ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
