[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DEFVST and DEFSTRUCTURE



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.