On 15 April 2014 13:11, Martin Baker <[email protected]> wrote: > On 15/04/14 14:56, Bill Page wrote: >> >> I doubt that Waldek wants backwards compatibility just for its own >> sake. > > > True but the impression I get with boot code is not just that its got > minimum documentation and minimum typing written in an obscure > language that is hardly documented itself.
There is nothing particularly difficult or obscure about BOOT. It started out as a preprocessor for Lisp of the kind that was originally envisaged by the developers of Lisp but never fully implemented. Instead Lisp programmers adopted s-expressions for both data and fuctions. http://en.wikipedia.org/wiki/M-expression The original developers of Axiom wanted something higher level but still close to Lisp as a stepping stone to a higher level language (SPAD). Inventing such domain-specific languages is actually one of the primary development paradigms for large systems based on Lisp. Since then several other variants of m-expression syntax for Lisp have appeared. Axiom ended up with a mixture of Lisp, BOOT, and SPAD but the use of BOOT was not universally accepted even by the Axiom developers and this was still an important issue for Tim Daly at the start of the Axiom open source project. One of the priorities of that project was to drop BOOT and adopt the generated Lisp code as the primary source code as the uniform "internal" language of the Axiom project. (I.e. going in the opposite direction to what you propose.) Within the original Axiom project once SPAD was (more or less) stablized there was a desire to incrementally upgrade BOOT code to SPAD where that was easily possible. At about this same time a decision was taken to develop Aldor, a replacement for SPAD that in principle would make it easier to replace all of Lisp and BOOT with higher level code. Unfortunately before this goal could be achieved the developers at IBM where forced to make their research project into a commercial venture which failed not long after. (To make a long story short.) > But, as far as I can make out, the whole > scratchpad project seems to have been used by IBM as a testbed for research > projects which, while being very clever, did not always pay off in terms of > producing maintainable code. Sometimes this sort of code seems to produce > unexpected anomalies and just reproducing that in another language doesn't > really solve the problem. I get the impression there are parts (only parts) > of the code where it would be better to rewrite from scratch, it may break > some old stuff which relies on the anomalies but it would be a much firmer > foundation for the future. > You might not be too surprised to learn that this is also a good summary of Reduce, Maxima, Maple, Mathematica and several other popular computer algebra systems. > Also I find SExpressions and their associated pretends quite evil (I know > there are a few cases where we have to use them). One of the advantages > of moving to SPAD is that it is more strongly typed, but using > SExpressions+pretends seems to turn it back into a loosely typed > language again. I think that calling SExpressions "loosely typed" is a misnomer. In fact SExpressions as a domain in Axiom/FriCAS are as strongly typed as any other object, it is just that they happen to correspond to the underlying data structure used by Lisp. It is pretend itself that is the (necessary) evil. > This may not be a problem for you guys, if you know what types to > expect, but for me it would lead to runtime errors which are harder to find > than compile time errors. I would find it much easier to go directly to high > level code and debug that. > I think everyone here agrees with you. > >> I do not see much arguing going on here, in fact it looks very >> cooperative to me. > > > I didn't mean to imply any animosity. I find this sort of discussion very > useful. I just did not want to annoy other people, on the group, if there is > any danger of going over old ground. > Yes it is old ground indeed but still worth going over. :) > >> But what you are advocating does seem both >> impractical and naive. > > > Perhaps but big projects can afford to waste resources, but developers here > seem so thin on the ground that it should be easier to coordinate better. > Why do you think it should be easier to coordinate better? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
