On Sunday 01 October 2006 21:42, root wrote: > thus it seems there are 2 boot languages implemented (but not defined). > my belief (but i don't remember) is that the src/boot directory came > into being as part of the process of switching to the new boot/shoe > language.
Yipe. This makes the cmucl port all the more interesting, in that it doesn't have a boot directory. I wonder how he pulled this off? Was some of the boot dir logic merged in? > you'll notice that the makefile in the src/boot directory explicitly > translates using the BOOTSYS image which contains the 'shoe' parser. > the makefile in the src/interp directory explicitly translates using > the DEPSYS image which only contains interpreted lisp files from > the interp directory and is NOT the same as the boot/shoe version. Scary. > rather than referring to them both as boot perhaps we should call > the one in the src/boot directory 'shoe', following bill's convention. I suppose I should know better than to ask, but since the eventual goal is to move the interp to Lisp anyway would a viable alternative be to "decode via rewrite?" I'm rather intimidated by the idea of trying to understand a set of files written in either of two versions of an unspecified language - mightn't it be more efficient to understand what they were trying to/did achieve (without necessarily following all of the subtle details) and then doing that using more "modern" coding conventions and documenting how it is being done this time? We might lose some optimizations initially but at least we would have clean, documented, modern code to work with. When I took a run at getting Axiom going on sbcl, I was more or less able to get the boot dir code working - at least, boottocl ran. But when I tried to get the cmucl port going, I seemed to run head on into some of the "Axiom wasn't designed with Lisp packages in mind" phenomena. I was reading the Davenport high level overview of the Axiom system this weekend, and I can't help thinking that maybe the way to go is to identify these key "top level" features and think about how they might be implemented today. For example (and this might be crazy, it's just a thought) wouldn't it be possible to use packages and the use/import/shadow concepts to handle some issues related to things like subdomains? Have the SPAD language create a new package when a new subdomain is created, :use the API from the parent domain, :export the key functionality of the new domain, and if some more efficient algorithm exists for something implemented more generally in the parent domain :shadow the implementation from the parent domain and define a new, optimized implementation? I'm afraid if we focus too hard on maintaining/duplicating exactly what the original Axiom code is doing, we're going to weave ourselves a very tangled web indeed. Boot, shoe, and spad ALL lack a formal definition, and as such we are more or less in the position of deducing the language from the code. Eeek. Shouldn't we be specifying what the language SHOULD be, and then re-merging the code into the new framework? I could be wrong of course, but at the moment poor Tim seems to be in the position of being the keystone and most of the arch as well. He's one of a VERY few people with a hope of decoding this as is, especially issues like optimization. Is there any way the rest of us could do something that would make decoding the whole of the maze unnecessary? CY _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
