--- Waldek Hebisch <[EMAIL PROTECTED]> wrote: > I think that Lisp code in Axiom needs substantial cleanup. There > is a lot of duplication (even more than in .boot files). It is > likely that 50% or more of Lisp code is unused or duplicated.
I wonder if there are Lisp utilities somewhere that could identify unused code for us. Hmm... > OTOH packages are main Lisp tool to organize code and we should > make better use of them. DEFINITELY agree. > From my point of view just moving > symbols from VMLISP into BOOT gains us nothing -- intead of two > closely tied piles of code we get one pile which is as closly > tied as before. Agreed. > I would like to see Lisp code reorganized along the following lines: > > 1) Portability wrappers and general purpose utilities. This should > abstract away most differences between Lisp implementations. YES. This is a must for all large Lisp projects. I suggest we also make use of widely used libraries already out there so we don't wind up duplicating work already done in this department (if the license is compatible with Axiom, we can include it in the tarball and conditionally load it based on the capabilities of the target build Lisp system - if it already has it great, if not we've got it in the tarball.) We might also (eventually) convert them into literate files - dunno if the upstream projects would accept that, but we could incorporate them. Tools I would like to check out: CL-FAD http://weitz.de/cl-fad/ (portable pathnames) usocket http://www.cliki.net/usocket (portable sockets) if we want to use threads, http://www.cliki.net/Portable-Threads if we need FFI access, http://common-lisp.net/project/cffi/ > File access and image dumping are prime examples of thing needed > there. This should be a file (possibly multiple files) in > src/lisp subdirectory and should be loaded into very first image > that we dump (so that we can use the exported functionality > during the whole build). I think that this code deserves it > own package (possibly multiple packages). Absolutely agree. One question - why do we want to dump Lisp images during the build again? I think this was explained a long while back, but I'm not recalling - it still seems odd to me :-(. > I noticed that you load inital-env.lisp from src/boot into the > first image. I do not think it is a goog idea: inital-env.lisp > contains a lot of Shoe specific code and misses many functions > that are needed later (some of them could benefit Shoe). > > 2) Axiom virtual machine: Lisp code needed to support output of > Spad compiler. This part should depend weakly on host Lisp. > Large parts of macros.lisp and vmlisp.lisp should go there. Sounds good. > 3) Part of "normal" code which are written in Lisp, those should > live in src/interp and src/boot as apropriate. > > I planned to start implementing part 1, but I have noticed that > you are doing similar but different things in build-improvements. Waldek, would it be possible for you to upload your "almost working on sbcl" tree? I'm working with sbcl mostly and it would be very handy, even if it's not 100% correct yet. Most of the tools of interest for portability haven't worked their way around to GCL yet so that also makes things difficult. > I should say stress one point here: simultaneously with moving > code around or implementing new functionality we should remove > old code. Agreed. We want to avoid "dead" code and prune it out - it only makes the system harder to understand. Perhaps some of it can be made "live" again but I'll bet a lot of it is dead for good. Cheers, CY ____________________________________________________________________________________Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
