[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DEFVST and DEFSTRUCTURE
- To: GLS at MIT-MC
- Subject: Re: DEFVST and DEFSTRUCTURE
- From: JONL@MIT-MC
- Date: Mon ,12 Jun 79 02:48:38 EDT
CC: (BUG LISPM) at MIT-MC, NIL-I at MIT-MC
To reply to a point or two you made in your TTY message
[b] the default state of the constructor name is a verrry
minor point since you can just do
#M (SETQ CONSTRUCTOR-NAMESTRING-PREFIX 'MAKE-
SELECTOR-NAMESTRING-STYLE () )
and thus standardize on the LISPM style.
I would like to see the LISPM provide these two global switches
also.
[c] many of the hairier options can't be supported in maclisp
(package stuff, for example), and its not clear that the
"storeage type" options improve things in the maclisp world.
But two areas *ought* to be compatible:
[c1] (DEFSTRUCTURE SHIP ...) should be the same as
(DEFSTRUCTURE (SHIP) ...)
[c2] now that LDB is available in maclisp, DEFVST should
allow subfields of components with "byte-specs"
As it happens, both DEFVST and DEFSTRUCTURE permit default
values for components to be specified the same way, e.g.
(DEFVST SHIP (SAILS 4)) like (DEFSTRUCTURE (SHIP) (SAILS 4))
I would undertake to fix [c2] if someone in the LISPM
community would fix [c1] and the point under [b] above.
[a] The fact that DEFVST is not called DEFSTRUCTURE lies in
the comment in the documentation, that as soon as NIL
needs structures to reflect VAX File-Descriptor-Blocks,
we will need a DEFBST (BITS-like structure); then
the NIL/MACLISP version of a DEFSTRUCTURE can deal
with the union of these more complicated objects.
Actually, far from being "flaming", your comments are
quite constructive, to get us to shape these things
up together.