drd@sii.UUCP (David Dick) (10/11/84)
b I am posting this for David Betz who has no direct access to news. ---- TO THE XLISP USER COMMUNITY As the original author of XLISP, I thought that I would say something about the current versions of XLISP that have been floating around the net as well as what I am planning for the future. The first and only version of XLISP that I have distributed is called version 1.1 and has been distributed through SIG/M, DECUS, usenet, and ARPA net as well as various bulletin boards and user groups. This version was intentionally kept small in order to allow it to run on small machines. It doesn't support more than a minimum set of lisp functions in order to leave enough space for user programs on machines with as little as 64K of memory. It is not intended to be a complete version of LISP but rather, is intended to be a useable subset on top of which objects, classes and messages have been built. XLISP is more intended to be a language to experiment with object oriented programming than a poor mans LISP. The only other version of XLISP that I am aware of is called version 1.2 and has been distributed through usenet and ARPA net. I don't know who is responsible for this version and I wasn't involved in its creation in any way. In many ways it violates my original goals for XLISP. I haven't tried to compile it for CP/M-80, but I doubt that it would fit in 64K and still leave much room for user programs. One of the main problems with XLISP 1.1 is that it doesn't use memory efficiently on machines with 16 bit addresses. Rather than implementing a cons using two 16 biinters and encoding type and garbage collection flags in the low order unused bits, I chose to use six byte nodes and allocate a byte for type and a byte for flags. This means that there is 50% less space available for list storage on machines with 16 bit addresses. XLISP 1.2 makes this situation worse by adding property list pointers to symbolic atoms. This means that a symbolic atom takes up 8 bytes rather than 6 in XLISP 1.1. Since a node is a union of all possible node types, this means that every node takes up 8 bytes. This is a very large waste of space on small machines. It may be that the advantages that 1.2 provides outweigh the disadvantages for some users. If this is the case, I would suggest that the new version be called YLISP or something like that to distinguish it from the original language and its successors. This brings me to the issue of the future of XLISP. Partly in response to some criticisms expressed in the Microsystems article that reviewed XLISP and partly due to my own desire to improve on my original program, I have nearly completed XLISP version 2. This new implementation is really a complete rewrite of the original. I have resolved the problem of 6 byte vs. 4 byte cons cells and have added many new LISP functions. I have also improved the implementation of objects by representing them with vectors rather than linked lists. The new version will support saving the XLISP workspace as well as doing expression I/O instead of just character and string I/O. A few features of the original will be missing. I have decided to eliminate the Keymap class. It was intended to be the start of a project to implement an object oriented editor. The code for the editor wouldn't fit and the current implementation of Keymap has bugs that, if fixed, would result in serious inefficiencies. Most of the features included in 1.2 will be present in version 2 (although the implementation is completely different). These features will include floating point, property lists, mapping functions, etc. Version 2 will attempt to be compatible with Common Lisp as much as possible. One of my most serious mistakes in XLISP was not making functions compatible with traditional LISP systems. I have received more calls about how fopen/fclose/getc/putc/fgets/fputs work than on any other topic. I am including more control structures including catch/throw, error trapping, a debugger that executes in the context of the error, let, block/return, etc. I have still refused to implement prog/go. I have included progn to allow for sequential evaluation of expressions. This is needed once if is made to work the way it is supposed to. Anyway, that is about all I'll say at the moment about version 2. Obviously, the introduction of version 2 is going to cause a fair amount of confusion since it is not a descendant of version 1.2. The only suggestion that I can make is to rename version 1.2 to YLISP version 1.0 to allow XLISP to continue on its original intended path. If people really want a more complete implementation of LISP, I could suggest that the object oriented programming support be removed from YLISP leaving a more normal implementation of LISP and also more space for user programs. The goal of providing a portable language that supports symbolic programming as well as object oriented programming on small machines will remain the goal of XLISP version 2. David Betz ...!decvax!sii!has70!betz (603) 623-3330 x2733 (work) (603) 625-4691 (home) P.S. If you have any comments on anything that I have said or want to make suggestions about what should be included in future versions of XLISP, feel free to contact me at the above network address or phone number.