Re: declare in with-slots

[piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)]

    From:	DECWRL::"Gregor.pa@Xerox.COM"  "8-Aug-88 1018 PDT"  8-AUG-1988 
    To:	Jeffrey Piazza <lisp::piazza>, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SL
    CC:	
    Subj:	Re: declare in with-slots

    Cc: common-lisp-object-system@sail.stanford.edu


	Date: Wed, 3 Aug 88 07:10:42 PDT
	From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

	...  For example,
	a common extension to declare allows:

	(deftype t-terminated-list () '(or cons (member t)))

	(with-slots (x y z) <instance>
	  (declare (t-terminated-list y))
	  ...)

    This declaration is clearly illegal according to CLtL.  

That's why I said "extension".

							    Page 158,
    paragraph 4 says:

      (<type> <var1> ...) is an abbreciation for (TYPE <type> <var1> ...)
      provided <type> is one of the types appearing in Table 4-1.

    The reason this extension is a bad idea transcends with-slots and
    friends of course.  No portable program analyzing program can analyze
    code that uses this extension.

I believe that's false.  A portable PAP can't use the declaration information,
that's all.  Of course, that might be a big lose, but declarations (except
SPECIAL) aren't supposed to affect semantics.  It would depend on what your
PAP was trying to find out.

    But, if a given implementation does in fact make this extension, it
    could just smarten up its with-slots (or symbol-macrolet) implementation
    to understand this case.

That's true.  I was thinking in terms of a portable implementation, which
would be impossible.  

	While you're thinking about this, consider what would happen if Common Lisp
	were extended to allow:

	(with-slots (x y z) <instance>
	  ...
	  (locally (declare (fixnum y))
	    ...)
	  ...)

	[CL doesn't currently allow this, but there's some sentiment to make this
	extension.]  Now with-slots would have to parse the entire body to get this
	right.

    As would a large number of other forms that could be affected by this
    change.  Putting the declare mechanism inside of symbol-macrolet, might
    be percieved to "solve" this problem.  It seems to me that the real
    problem with this case would be profusion of declaration hair though.



	What's the point of symbol-macrolet, then, if not to be the form which says
	"pretend foo is a variable, even though it's not"?  You're suggesting that only
	with-slots wants to play "let's pretend," and that there's some different roles
	that symbol-macrolet fills?  I doubt it...

    This code from Jim Kempf shows how I was intending to have with-slots
    expand, and shows clearly why I didn't think symbol-macrolet was the
    place to support this.  

Just because the expansion is relatively simple doesn't, of course, mean that
it's really the "right" thing to do.

What if I, a random user, wish to write e.g. my own "with-file-attributes"
macro, that lets me access things like the read and write dates for a file as
symbol-macrolet "variables".  Not being an implementor, I don't have access to
the system declaration-parsing stuff, so I can't support declarations in the
way you're proposing for with-slots and with-accessors.  I cry "no fair".

I am aware of no other macro which has to parse declarations -- they just get
pushed off to some special form or other.  I think that, for what you're
trying to do, you have to make symbol-macrolet be a special form, and do
declaration processing there.

/JEP

PS on a slight tangent:  What's the meaning of:


(with-slots (x y z) <instance>
  ...
  (locally (declare (special y))
    ...y...)
  ...)

Is the y inside the locally the special variable or the slot?  I believe the
current definition would make it the slot.  I also believe that's anomolous.