JONL@MIT-MC 11/18/81 13:31:02 TOPS-20 stuff [What is this? --gsb [What do you mean "what is this?". Was this in the file when you started to edit it or something? -Alan [yes. i dyked out everything i could account for, and this i couldn't. --gsb]]] ---------------- UMLMAC Stuff [GSB] DOLIST and DOTIMES no longer accept an optional third form : (dolist (var list ) body...) Eventually a form in that position will be a form to eval to produce the final value of the dolist or dotimes. WITH-OPEN-STREAM (WITH-OPEN-STREAM (
) ...) is evaluated and bound to the result; is evaluated in that environment. When the code exits, if whatever evaluated to is a file or SFA, it is CLOSEd. The value of is computed and saved uninterruptibly to prevent timing screws. Changing the value of does not affect the behavior of the code, as the stream is saved in a temporary variable. [Unless changing the value of the variable also works on the LispMachine (210 and 86), I wouldn't bother to mention this. -Alan [yeah. I should check, but i think that changing the value of the stream "works" in lispm code, but is not documented... -gsb]] WITH-OPEN-FILE (WITH-OPEN-FILE ( []) ...) Binds to the result of opening with options , and then evaluates . The file is CLOSEd on exit of any kind. In general, (WITH-OPEN-FILE ( . ) ) is equivalent to (WITH-OPEN-STREAM ( (OPEN . )) ) That is, the behavior of WITH-OPEN-FILE with respect to open options (both the number of them and what ones are accepted) and the response to file system errors, is determined by the OPEN function. [I would mention WITH-OPEN-FILE first and tell people that it is probably what they want. WITH-OPEN-STREAM should be presented as an obscurity most people will never see. -Alan [ok -gsb]] ---------------- MLMAC stuff [GSB] Variable definition forms have changed a bit. There is now: DEFVAR (DEFVAR [ []]) same as always: declares special, and, if is present and is not bound when this form is evaluated, then is evaluated and assigned to the result. DEFPARAMETER (DEFPARAMETER []) This is what is currently DEFCONST. It behaves like DEFVAR, except the initialization of the variable is unconditional. Hence the form is not optional here (if you do not want to use one, you should be using DEFVAR). The name DEFCONST is being phased out because of potential confusion with... DEFCONSTANT (DEFCONSTANT []) This defines to be a "manifest constant". An initial value is always given to the variable. In principal, it is an error if at DEFCONSTANT time there are any special bindings of in effect, or if the variable has a global value not EQUAL to the value of . Maclisp will not check the former, and currently does not check the latter. DEFCONST This is now called DEFPARAMETER. The name DEFCONST will continue to work indefinitely, and turn into DEFPARAMETER. Note, however, that the previous DEFCONST allowed one to not specify an form; DEFPARAMETER requires one. [Is all this as per Common Lisp? I don't have my collander handy. -Alan [yes. Which is the reason for the change. -gsb]] ---------------- What to do? DEFVST, DEFSTRUCT, EXTEND Should we flush DEFVST? VECTORs? STRINGs? (The NIL ones using EXTEND) Should we flush EXTEND? (If this, must flush all of the above.) [Well, certainly we can't flush this stuff without warning people and asking them if they are using it. Perhaps we are stuck with having the autoload properties there for eternity. I do wish that there were defstruct autoload properties as well though... -Alan] Do people need anything that DEFVST provides that DEFSTRUCT cannot? How about if some extra (small runtime support) stuff were provided for doing the pseudo-typing things? THrow in the USRHNK stuff to keep things modular? [Sounds good. JonL always complained that the defstruct named types couldn't REALLY be distinguished from random hunks because you might make a hunk by hand who's car was SPACESHIP, while the defvst class system wasn't nearly so easy to fake out. Do we care? If people are really worried about this, couldn't we easily throw together something even better involving allocating our own SPACESHIP segments? (Heck, we could do it so that you didn't use ANY slots in the structure to flag what it was! Gee, this seems like such a good idea, why haven't I already done this?) -Alan [How do you expect to do that? What i've always wanted was just something a little better than the structure name, which is not enough. Like an uninterned symbol, so you can make it a macro/source-trans/optimizer and get nifty behaviour that way, and use a user-hunk thing to dispatch off of property(s), etc. what you think? --gsb]] ---------------- Do something about the LSETS file. n.b. This is one of the only "nilcom" files actually used in NIL! Coordination needed here as NIL really uses it. [What is it? -Alan [arbitrary and capricious set functions --gsb]] ---------------- NILCOM;RESOURCE implements DEFRESOURCE ala Lispm. Same-source runs in NIL, PDP-10, and Multics Maclisp. Becoming heavily used in NIL system. Not clear how reasonable this sort of implementation is for Maclisp, on two counts: the reasonableness of doing GC in the limited address space as opposed to trapping the storage, and also the relative slowness of unwind-protect in Maclisp compared to (say) Lisp Machine Lisp and NIL. [Wouldn't the best thing for MacLisp perhaps be a DEFRESOURCE that simply always LOST the allocated resource when thrown through? Perhaps there should be an option to DEFRESOURCE controlling wether you want it to go to the trouble of making an UNWIND-PROTECT? It could be a switch that defaulted one way in MacLisp and the other way in NIL. We should ask BSG haw expensive a Multics unwind-protect is to set up and exit through. -Alan [Probably. This changes the orientation of the code, however, because you need to be able to miss deallocating the object, but not hold on to it forever, which the current design would do (barring clear-resource or something catastrophic like that). -gsb]] ;;;Local Modes: ;;;Mode:Text ;;;Fill Column:70 ;;;End: