Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!wuarchive!emory!ogicse!zephyr.ens.tek.com!tekchips!tekgvs!toma From: toma@tekgvs.LABS.TEK.COM (Tom Almy) Newsgroups: comp.lang.lisp.x Subject: Re: xlftab.c:funtab[] & other questions Message-ID: <8457@tekgvs.LABS.TEK.COM> Date: 20 Nov 90 17:08:28 GMT References: Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy) Distribution: comp Organization: Tektronix, Inc., Beaverton, OR. Lines: 44 In article jsp@glia.biostr.washington.edu (Jeff Prothero) writes: >Why are the xlftab.c:funtab[] entries so carefully numbered? Beats me. I was careful to maintain the numbering until I ran out of slots. Now I just append to the end! The table is only actually scanned once (during initialization), and the scan is terminated by the null entry at the end. >What is going to break if the numbering is changed? Primarily the >image save/restore stuff? >Why can't/shouldn't those things which will break key off the function >names instead of the table offsets? The first entries, for the read macros and the intrinsic message selectors, are referenced by offset for initialization (probably due to laziness, but I am not sure). As long as you leave these alone, nothing else breaks. (but see below) >Why are extra slots reserved at the end of funtab[]? You can delete them. >What's the point of image save/restore? Should saved images be >portable between machines or versions? You can save your workspace, and go back to it at a later time, like in Smalltalk or APL. You can use it as a snapshot, and later go back in time. It is the only way to do a vector/string memory defragmentation (except for people who use my files dldmem and dlimage, in which case the defragmentation is automatic). Saved images are not portable between machines because these are binary files and the representations can change (big vs little endian, wordsize, etc). They are also not portable if funtab changes. >Would it be hard/pointless to write code to convert the xlisp >state into initialized C header files, so that the xlisp state >could be portably compiled into an application? The state is mainly a large initialized linked list which can not be statically declared in C (you need to execute code to set the links). IMHO it would also be pointless since applications should be distributed as xlisp source rather than C files (what if the user doesn't have a C compiler?). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply