Clarification Comments (long)

[shebs%utah-orion@utah-cs.arpa (Stanley Shebs)]

The following long message is a set of knee-jerk reactions to Guy's list
of suggested clarifications.  They are (more or less) keyed by page, as
in the printed list handed out at the meeting.  You'll need the list,
since I left out context to save space.

1 There are at least two reasons for having undo operations.  The most
obvious is for user-friendliness and mistake-fixing, while the other
reason is to support really arcane things.  I would put the various
"un" package functions into the first category, while something like
makunbound is more in the second.  If CL is the subset used for portable
programs, then it seems to me that functions whose sole purpose is to
improve the user interface are less important; they are unlikely to
show up in programs to be ported.  From that point of view, a general
undo is not appropriate for CL, although certain specific things like
delete-package might be OK.  If an implementation *does* have an undo,
I would like to see it as elaborate as the facilities in Interlisp -
fixing a mistaken (setq *macroexpand-hook* #'tailp) shouldn't result
in (makunbound '*macroexpand-hook*)!

47 This is OK, although it feels a little uncomfortable to include the
name of a local keyword variable in a proclamation that may be in
another file.  Bye bye alpha conversion...

51 Yes!

56, 58 Go for it.

60 Yes, on the principle that it might allow more optimization
(I have here in my hand a list of 203 known compiler optimizations that
this would make possible...).

82 Sounds like a good idea - I even thought back over old code to
see it would simplify any complicated conditionals.  Sadly, I couldn't
remember any.

107 Yup, on the principle of decoupling functionality.

113 Sounds OK, but do I vaguely remember battles on possibly difficult
problems with this one?

120 Yes, on the principle of orthogonality, but it'll fatten up the
code a bit (unless of course one has the fabled "sufficiently good"
compiler).

130 I didn't realize until now that tagbody does have a restriction
on body contents.  That seems wrong to me.  Presumably lots of things
will macroexpand into tagbodies, and every one inherits the same
restriction.  Worse, one implementation's dolist will macroexpand
into a tagbody, while in another, it will be a special form.  Why
not say that integers and symbols are tags, and everything else is
a form? Or that all non-lists are tags?

130 Might have same problems as previous point, but it seems less
likely to be a problem.  OK by me (but needs more thought).

144 Seems reasonable, although I'm sure there's some subtle point
I'm missing about why macro-function should be defined this way,
and symbol-function should not.

145 Yes!  Although it needs a fairly careful specification.
Should parse-body work on all def* bodies?

145 Yes.

145 Yes. (Why so many clarifications for macros anyway? :-)

158 Yup.

159 Good.

162 OK.

172 Yes, although it breaks much code...

186 Doesn't seem *wrong*, but not clear why one can't explicitly test
symbol-package and intern instead.  Sounds like a frob.

187 Ah yes, making the spec conform to reasonable implementations!

202 Sure.

212 Isn't a proposal that's *already* been accepted that we could
follow?

226 "All in all, it's just another frob in the spec..."

239 This one seems really unmotivated - why the bits and not the
font anyway?  Perhaps we could add keywords to char comparison
to tell which parts of the char are to be considered :-)

249 I think the effect of mapping over circular lists should be
to delete the offending program and harass the user every time
he/she starts up the Lisp thereafter.  Trying to make all of the
functions work on arbitrarily hairy list structure involves too
many imponderables - mapcar and "circular" lists is just the tip
of the iceberg.

268 Yes - I always assumed this one slipped through the cracks.
Should it work on circular lists? :-)

275 Yes.

283 Yes.  Does anybody actually have an implementation for which these
functions would be more than structure accessors that already exist
internally?

293 Yes.  The array functions are, shall we say, sketchy; these seem
like worthwhile additions.  There are probably others.

295 Yes - how would anyone adjust *part* of an array?

297 Sounds OK to me, but I haven't studied the issues closely.

297 Yes, to be consistent with p. 295 clarification.

307 Yes.

307 Yes, and should this be extended to cover both plain slot names
and ones with conc-names added?  Or is the normal "functions stepping
on each other" protocol sufficient?

321 Seems like a frob, but there's no real reason not to do it.

322 Makes sense.

328 Yes, but I would go further and say that there are no requirements
*at all* about which streams are bound to which, or whether any are
bound at all!  But then one would have to define more behavior
(the issue has already come up of yes-or-no-p being called when one
is running a batch job, and doesn't plan to login until next week).

425 Yes.

439 Pretty dramatic clarification!  This isn't even hinted at in the
book.  OK by me, although made unnecessary if uncompile is defined.

439 Yeah.

439 This constrains the implementation to save source code somewhere,
which is more of a nuisance than a hardship.  This is really another
one of those user convenience things.

440 Sure, with the same proviso as for inline functions, that a macro
call may not be traceable because it's been expanded already.

443 Now we know how to implement apropos! :-)

447 What's another function when you've got hundreds? Sure.

							stan