--- Ralf Hemmecke <[EMAIL PROTECTED]> wrote: > To me it doesn't matter whether the code is in BOOT or LISP. BOOT is > not well documented and LISP is too low-level for my taste. Why > cannot all this be written in Aldor? And without tricks, please. > And, of course, well documented in pamphlets.
I'm beginning to agree that everything that can be in Aldor should be, for two reasons: a) It's more self contained - e.g. the parts that involve being compatible with anything except Axiom/Aldor are minimized. b) It will minimize the "communicating between multiple languages" and "neeed to learn multiple languages" problems That said, if Tim has already redone a given part in Literate Lisp, it's not worth redoing his work in Aldor for the forseeable future - work of that quality can't be easily duplicated and for certain aspects of Axiom Lisp is in fact a good match. > The problem is that the Aldor compiler is still not open source. :-( > But it already comes with a primitive FOAM-interpreter. I have no > idea how difficult it would be to write a new interpreter from > scratch in Aldor compared to clean the old interpreter/spad- > compiler code. I can't help wondering if the material in the Reference section of the Aldor Users Guide might be enough for us to define at least a basic Aldor compiler in Lisp, and build on that. If I'm understanding correctly, most of what we would like to use from Aldor actually is available in source code form, with the BSD+extra rights for Aldor.org license? And the most critical, libaldor and libalgebra, are Manual Bronstein's work and might be releasable under plain Modified BSD without having to unravel the Aldor.org knot? If this is the case, it might be workable to implement a minimal Aldor compiler in Lisp, building off of the knowledge already existing in the code for SPAD compilation and the Reference section in the Aldor User Guide. Call it A# to avoid confusion, at least once we have a working version. I imagine we might want to develop Aldor a bit, and if Aldor.org doesn't follow our changes it would be better not to confuse the two. That resolves two things: a) Both our existing Lisp code and other useful Lisp code can still be easily handled and integrated into Axiom, since the foundation language will still be Lisp and b) will let us get down to business ordering, documenting, designing, and making robust the Aldor level algebra of Axiom. > >>Right. That is the reason why it is actually easy to learn > >>Aldor. There are only a few language constructs that you have > >>to remember. It is much harder to learn what is available > >>through libraries. Unfortunately, there are several libraries > >>around and except that libalgebra.al builds upon libaldor.al, > >>there are many incompatibilities between libaxiom and > >>libalgebra. Would it be a forlorn hope that, if Aldor is easier to learn because there are only a few language constructs, its compiler might also be easier to define? > > In Axiom I think we only get to use libaxiom. Using the Aldor > > native library would be very complicated because of differing > > internal implementations. Right? > > The Axiom algebra code must be put into proper pamphlets anyway. It > should be translated into Aldor. So way not taking the libalgebra > sources of Aldor? That spares some rewriting of the code. Don't > believe that it is so simple to translate SPAD into Aldor. I > somehow think it would be cleaner to start building from existing > Aldor libraries. I'm beginning to agree. They would still need to be audited to make sure they are up to Axiom's standards as Literate Documents, but if they are cleaner and more robust while building on the same basic ideas as Axiom's algebra it would make many things simpler. > Having for a while two branches while adding code from Axiom to the > Aldor libraries. That is a lot of work, but I would feel better > concerning the foundations of the domains and categories in Axiom. I think a more robust foundation will save work down the road. The grunt work of converting source code into literate papers documenting the ideas will be the same regardless. > What I really don't like is that in Axiom sometimes information is > added by the compiler/interpreter which does not exist in the .spad > file itself. Type information that is guessed by the compiler is > just an example. Hmm. But aren't there some cases where you want this, like (say) knowing that 4 is a real integer without having to explicitly say that? (Sorry that's probably a dumb question). > > I think it should be possible to implement NNI (NonNegative > > Integer) and PI (Positive Integer) without the use of SubDomain. > > Maybe just an import of Integer would do? I do not know of any > > specific case where the knowledge that NNI and PI are "subdomains" > > of Integer is actually used. > > Oh, that is a good suggestion. But maybe some code relies on > elements being NNI or PI. To find this out, one can only go by hand > through all the tons of code lines. :-( So it cannot be discarded > immediately. > > But when transferring to Aldor, one has to decide anyway what to do. I think a tutorial on moving SPAD code to Axiom will eventually be a must. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
