--- Bill Page <[EMAIL PROTECTED]> wrote:
> On October 23, 2005 2:51 PM C Y wrote: > > > > So the way things are organized is SPAD built on BOOT built > > on Lisp? And the core reason for this is that BOOT makes it > > much easier to build SPAD than building it in straight Lisp > > would be? > > Of course as Tim Daly would likely point out, that is a matter > of opinion conditioned by personal style and degree of > familiarity with programming in Lisp. But it is clear that > many (most?) of the original Axiom developers seem to have > held such a view. Hmm. I guess in a situation like that he who codes first and best wins :-). I do know enough about language debates to know that no resolution is possible and such discussions have no end ;-). I need to study what's going on much more carefully to see if I can "catch the feel of" the intent of BOOT. > > This being the case, we should be very clear in the literate > > documentation on the purpose for each language, the reasons > > behind it, and the advantages to using it ... > > We all seem to agree that documentation is key to Axiom's > future. The question is: how can we make sure that this > documentation gets written? In this particular case, that would require someone knowing quite a lot about the BOOT language and its design philosophy. Aside from the time honored method of drawing up a list of such people and bothering them ;-) the only way I know to do it would be to start from the beginning and sort of "learn by analysis" what the code is doing, and deduce from that the philosophy and intent of the program. > And after it is written, that it > is accessible when someone needs it? I have been devoting some > effort to building tools to make this easier, such as the new > support for pamphlet files in the Axiom wiki > > http://wiki.axiom-developer.org/axiom--test--1 > > So now you can view the literate documentation for each module > of Axiom source online and correcting or expanding the > documentation is as easy as clicking 'edit' and then adding > or changing whatever you want. That should be an excellent answer to increasing accessibility and the possibility of small scale corrections, but to build the foundation we need someone who can write up the original goals and how BOOT achieves them. > But I am worried that just making it easy will not in itself > make it easier to write useful documentation because in order > to write documentation, you first have to understand what you > are writing about. And without existing documentation *that* is > the really hard part. Bingo. In some ways I guess that's why the thought of major changes at that level doesn't scare me as much as it should - thanks to the literate programming ideal the amount of work needed to do the job properly is virtually the same for a rewrite as to understand properly the current code. The advantage should be that once done it won't have to be redone in any significant way for a long, long time. > > So BOOT was made different from Lisp to allow SPAD to be > > different? And the major objection to lisp is that it is too > > low level? (Sorry if those are more dumb questions, I'm just > > trying to get a sense of the modes of thinking involved.) > > Maxim1: "there is no such thing as an easy job" > Maxim2: "there is not such thing as a dumb question" > > Yes, I think you understand my point. But it is not quite > correct to call lisp "too low level". For many purposes lisp > can be considered to be a very high level language. But the > concept of level here is relative to the purpose. So, for the > purpose of expressing abstract mathematics, yes lisp was too > low level. Ah :-). Got it. > > > Footnote: > > > > > > 1\ Of course Aldor, as the next generation of SPAD, was > > > actually written in "C" not lisp (that is another story). > > > But the design of Aldor was inherited from SPAD. > > > > So if at some point Aldor becomes free and we can switch to > > it, what are the implications for Lisp and BOOT in Axiom? > > > > Ah, another very good question! > > Even with Aldor to replace SPAD, lisp and BOOT are still very > important for the interpreter part of Axiom. The interpreter > provides the user interface and must translate user instructions > into operations from the Axiom library. Hmm. A bit off topic, but I've been wondering about the interpreter vs. compiler a bit - IIRC there have been one or two cases we've run into where the interpreter handles code differently than the compiler does - e.g. making assumptions the compiler won't. I can see why this would be desirable (programming often calls for avoiding assumptions that are normally quite useful to the user) but it should also be very carefully documented and discussed, because it also would seem to allow for the situation of someone testing code in the interpreter, saving it to a file, and getting different behavior when they try to compile and run it. Am I missing something? > It is possible to go further and to imagine writing the Axiom > interpreter itself in Aldor. One can guess that this is one of > the reasons that Aldor was specifically designed also to work > as a stand-alone compiler and not just as the Axiom library > compiler like SPAD. I do not know how much work, if any, has > ever been done along these lines. Unlike changing Aldor for > SPAD as the library compiler, changing the interpreter to Aldor > would not be just an incremental change. The interpreter would > have to be completely re-written from ground up. Eeek. Of course, Tim already mentioned that the interpreter needs to become a literate document too, so perhaps while it's being documented it could be ported... > Personally I am not sure whether re-writing the interpreter in > Aldor would be such a good idea. Certainly one would gain the > advantage of easily working at the same level as the code in > which the mathematical library is written. But outside of it's > application as a replacement for SPAD, Aldor is still largely > an experimental language. I think it's advantages and disadvantages > relatively to lisp and BOOT or other high level object-oriented > languages like Java, Python, Haskell and Ocaml are largely > unknown. In a sense, this is where research in the Axiom project > left-off when the money ran out... But it is one of the parts > of Axiom that intrigues me most. Hmm. Well, if Axiom is modular enough perhaps different interpreters could be swapped in and out to see how they work, if different implementations were coded up? > > OK. In that case proper documentation becomes of paramount > > importance, and I would say one of our highest priority tasks > > (if BOOT survives the Aldor conversion) should be to get our > > languages documented so we can have a reasonable expectation > > of people being able to learn and program in them quickly. > > I don't think it is possible to say that too often unless > saying it happens to get in the way of actually doing it ... > :) I'm innocent here - I don't know enough about BOOT to even ask the right questions on the first try! It would be nice if one of the original architects could be lured into the free project to write up their work... > > So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process > > wherein each level enables a more abstract or "high level" style > > of programming than the previous stage? > > Hence the name "BOOT". Oh! Duh :-). It's beginning to make sense, little by little... > I would say that "productivity" is not so much the issue as > "creativity". Working at a higher level of abstraction allows > you to concentrate on different aspects of a problem. And of > course this mirrors how a lot of mathematics is also done. So > this approach fits the application quite well. True. > > I think the effect of that tension is to keep people > > continually arguing about and defending their design > > decisions, which is likely to result in more robust > > decisions in the end. > > Maybe that is a good thing, maybe it is a bad thing. I think > we have to try to make sure that it does not lead to a stalemate > and end up reducing everyone's motivation to make progress > towards improving Axiom as a whole. Definitely. I think Tim would agree that with or without BOOT in there Axiom is worth moving ahead with full steam. And the beauty of it is the mathematical part (e.g. the meaty part) doesn't have to care about BOOT vs. Lisp :-). > I think one thing that we can > use it for is to use it as motivation to continue writing about > and hopefully, documenting more of Axiom. Agreed. I think maybe I'm catching this bug a bit too much, but I'm beginning to like this whole "write the document, with the code being simply a part of the document" idea, regardless of how much time it takes to get up to speed. If I'm thinking about it correctly, language issues become a bit moot at that point - in theory someone could take a document, read it, redo all the code segments in their language of choice, and hey-presto a port to a new language. I know it's not quite that simple in reality, but it would be a lot easier than any other way I've ever heard of. And you also have the advantage that in order to write a proper document, the coder needs to really understand what he/she is doing. Which may solve quite a few problems right there ;-). > > Normally a concern in an open source project is handling things > > in such a way that we attract developers, but this is not an > > ordinary open source project and so I should worry less about > > any barriers to entry posed by multiple languages and more about > > how they benefit the quality and power of the result. > > Yes, the "spin" you put on it is important. I think you are > right to be concerned about how to attract developers to the > Axiom project. One thing I am sure Axiom can offer open source > developers is the challenge of working on a leading edge > research project. And I think this is made even more enjoyable > with the knowledge that this line of research already dates > back more than 30 years. I think once the core parts of the system are documented and stable, we will be able to begin building momentum. Axiom has the virtually unique challenge of needing to attract mathematical authors as much as (or even more than!) regular coders. As with most such things, momentum is only built slowly over time - as a new project (at least as open source) Axiom is currently risky and not well established. The only cure for this is time and work, but I think Axiom has got what it takes. I think Aldor's release as free software, if it does happen, will set a lot of events in motion. Probably including the re-tooling of Aldor into pamphlet files ;-). Now, back to the murky world of units and dimensions! :-) Cheers, CY __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
