[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Ballot results
- To: common-lisp at SU-AI
- Subject: Ballot results
- From: STEELE at CMU-20C
- Date: Wed, 13 Oct 1982 20:08:00 -0000
?????????????????????????????????????????????????????????????????????????????
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
? % ================================================================= % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + # / The October 1982 Common LISP Ballot / # + $ = % ?
? % = $ + # / RESULTS / # + $ = % ?
? % = $ + # ///////////////////////////////////////// # + $ = % ?
? % = $ + ############################################### + $ = % ?
? % = $ +++++++++++++++++++++++++++++++++++++++++++++++++++++ $ = % ?
? % = $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ = % ?
? % ================================================================= % ?
? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ?
?????????????????????????????????????????????????????????????????????????????
Here are the tabulated votes on the October 1982 Common LISP Ballot. For
each issue the summary vote shown between "***" is what I take to be a
consensus, with a "?" added if I am a bit uncertain. I will edit the
manual according to these guidelines unless someone screams loudly and
soon over some issue. A few of the issues had a very mixed response;
these I have labeled "Controversial" and will take no immediate action on.
--Guy
1. How shall the case for a floating-point exponent specifier
output by PRINT and FORMAT be determined?
(a) upper case, for example 3.5E6
(b) lower case, for example 3.5e6
(c) a switch
(d) implementation-dependent
Issue 1: *** B? ***
Hedrick: B Wholey: - Fahlman: B Weinreb: B Killian: B
Zubkoff: C Moon: B van Roggen: D Masinter: A RMS: B
Dyer: B Bawden: - Feinberg: B Ginder: B Burke et al.: B
Brooks: - Gabriel: A DECLISP: B Steele: C Dill: D
Scherlis: - Pitman: B Anderson: B
2. Shall we change the name SETF to be SET? (y) yes (n) no
Issue 2: *** N ***
Hedrick: N Wholey: N Fahlman: N Weinreb: N Killian: X
Zubkoff: Y Moon: N van Roggen: Y Masinter: N RMS: N
Dyer: N Bawden: N Feinberg: N Ginder: N Burke et al.: N
Brooks: N Gabriel: N DECLISP: N Steele: N Dill: N
Scherlis: Y Pitman: N Anderson: N
Killian: I have been convinced that renaming SETF to SET would be
wrong because it would require changing lots of old code. But,
you seem to have ignored the rest of my suggestion in your
ballot, namely eliminating those horrid "F"s at the end of
several function names (INCF, GETF etc.). If you don't do this,
then you're being inconsistent by not naming PUSH PUSHF, etc.
The "F" at the end of "SETF" would then be there purely for
compatibility, and could be renamed when another Lisp dialect
is designed, years hence.
Pitman: I think we should do this, but not at this time.
RMS: I very strongly do not want to have to change uses of the
traditional function SET in the Lisp machine system.
Feinberg: A better name than SETF (or SET) should be found.
3. Shall there be a type specifier QUOTE, such that (QUOTE x) = (MEMBER x)?
Then MEMBER can be eliminated; (MEMBER x y z) = (OR 'x 'y 'z). Also one can
write such things as (OR INTEGER 'FOO) instead of (OR INTEGER (MEMBER FOO)).
(y) yes (n) no
Issue 3: *** Y? ***
Hedrick: X Wholey: Y Fahlman: N Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: N Masinter: Y RMS: -
Dyer: X Bawden: Y Feinberg: Y Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: N Steele: Y Dill: Y
Scherlis: Y Pitman: Y Anderson: -
4. Shall MOON's proposal for LOAD keywords, revised as shown below, be used?
(y) yes (n) no
Issue 4: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: X RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: X Anderson: -
Moon: I thought we agreed to make LOAD take a stream as its first argument,
instead of a pathname, and flush the :STREAM keyword. :ERROR should
control only "file does not exist" errors, not "host down", "directory
does not exist", "illegal character in file name", "no access to file",
and "file cannot be read because of disk error". Nor should it affect
errors due to evaluation of forms in the file. So I think it needs a
better name; how about :NONEXISTENT-OK?
Masinter: :ERROR, :SET-DEFAULT-PATHNAME options to LOAD should be
rationalized with OPEN; the handling here of search paths should
logically be handled by passing on some of the options from LOAD to OPEN
rather than having LOAD do special path-name processing. This is because
users who manipulate files want to do similar hacking, and the mechanism
should be common.
Pitman: I would vote YES except: As suggested by someone when it was
proposed, any mention of packages should be stricken pending the release
of a package system specification.
Dill: :PACKAGE & :VERBOSE should be flushed, since they are package system
dependent.
5. Shall closures over dynamic variables be removed from Common LISP?
(y) yes (n) no
Issue 5: *** Y? ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: N Killian: -
Zubkoff: - Moon: - van Roggen: Y Masinter: - RMS: -
Dyer: X Bawden: - Feinberg: Y Ginder: Y Burke et al.: -
Brooks: - Gabriel: N DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: N Anderson: -
6. Shall LOOP, as summarized below, be included in Common LISP?
(y) yes (n) no
Issue 6: Controversial
Hedrick: N Wholey: N Fahlman: N Weinreb: Y Killian: Y
Zubkoff: X Moon: - van Roggen: N Masinter: X RMS: N
Dyer: Y Bawden: Y Feinberg: N Ginder: N Burke et al.: Y
Brooks: N Gabriel: X DECLISP: Y Steele: N Dill: N
Scherlis: N Pitman: N Anderson: N
Fahlman: I am in favor of adding the LOOP package as described (once it is
completed) to the language as a portable yellow pages module. I feel
rather strongly that it is premature to add LOOP to the white pages.
Zubkoff: The LOOP macro should be kept in the yellow pages until we've
had a chance to use it for a while and determine whether or not it is the
"right" thing.
Masinter: I feel strongly that the white pages SHOULD include a LOOP construct.
I care less about which one, but I like most of Moon's proposal better than DO
and what I saw of LetS. I'd get rid of AND and ELSE. I don't understand
if the "COLLECT" lexical scoping includes scoping under macro expansion.
Pitman: As a yellow-pages extension is ok by me. I strongly oppose its
placement in the white pages.
Feinberg: We should carefully examine all iteration construct proposals
before committing to any particular one. I feel strongly about
this. I would very much like to see complete documentation
on Loop and any other loop construct which might be included
in Common Lisp, especially before we decide to incorporate them
into the white pages.
Gabriel: I believe that a LOOP construct of some sort is needed: I am
constantly bumping into the limitations of MacLisp-style DO. The
Symbolics people claim that LOOP, as defined in the current proposal, is
well thought-out and indispensible. Not having used it particularly, I
cannot pass judgement on this. I advocate putting LOOP into the hottest
regions of the Yellow Pages, meaning that people should use it immediately
so that any improvements to clarity can be made rapidly. The best possible
LOOP should then be moved to the White Pages.
My prejudice is that LOOP code is very difficult to understand. On the
other hand, closures are difficult for many people to understand, and
perhaps the difficulty is due to unfamiliarity in the LOOP case as it is
in the closure case.
In my current programming I do not define my own iteration construct
(though I have in the past) because I've found that other people (such as
myself at a later date) do not readily understand my code when it contains
idiosyncratic control structures. If we do not standardize on a LOOP
construct soon we will be faced with the fact of many people defining
their own difficult-to-understand control structures.
7. Regardless of the outcome of the previous question, shall CYCLE
be retained and be renamed LOOP, with the understanding that statements
of the construct must be non-atomic, and atoms as "statements" are
reserved for extensions, and any such extensions must be compatible
with the basic mening as a pure iteration construct?
(y) yes (n) no
Issue 7: *** Y? ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: Y van Roggen: N Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: N Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: N Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: N
Feinberg: I don't think we should make any commitment at all, even to this
extent. Loop is too nice a word to give up before we even agree about
installing it into the language.
8. Shall ARRAY-DIMENSION be changed by exchanging its arguments,
to have the array first and the axis number second, to parallel
other indexing operations?
(y) yes (n) no
Issue 8: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: Y
Dyer: Y Bawden: - Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: Y Anderson: Y
9. Shall MACROEXPAND, as described below, replace the current definition?
(y) yes (n) no
Issue 9: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: - Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: X Anderson: -
Killian: This is ok as far as it goes, but I intend to suggest
additions when I find the time.
Masinter: This seems right but not quite fully specified, e.g. LAMBDA-MACRO.
Pitman: I would vote YES except:
I am uncomfortable with saying that a form returns two
values and then returning only one (letting the rest default to NIL).
Does Common-Lisp specify anything on this? In any case, I would ammend
the (cond ((and (pairp ...) ...) (values (...) t))
(t form))
to (cond (...) (t (values form nil))) to make it clear that two values
are always returned. If this modification is made, I am happy with this
proposal.
10. Shall all global system-defined variables have names beginning
and ending with "*", for example *PRINLEVEL* instead of PRINLEVEL
and *READ-DEFAULT-FLOAT-FORMAT* instead of READ_DEFAULT-FLOAT-FORMAT?
(y) yes (n) no
Issue 10: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: X
Dyer: N Bawden: N Feinberg: Y Ginder: Y Burke et al.: X
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
RMS: I would prefer a character other than *, such as "-".
It is easier to type, and easier to type correctly.
Bawden: I am in favor of variables named *FOO* over variables named FOO only
when that doesn't introduce an incompatibility with existing Lisps. That is
why I voted NO on 10, because it involved an incompatible change to variables
like PRINLEVEL. I voted YES for 11 because currently we have no named
constants as far as I know so there is no incompatibility.
Burke et al.: I really like only ONE "*" at the beginning of the name. I got
tired of shifting for two years ago, but conversely couldn't stand to
not have the specialness of the variable not be obvious.
11. Same question for named constants (other than T and NIL), such as
*PI* for PI and *MOST-POSITIVE-FIXNUM* for MOST-POSITIVE-FIXNUM.
(y) yes (n) no (o) yes, but use a character other than "*"
Issue 11: Controversial
Hedrick: Y Wholey: N Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: N van Roggen: Y Masinter: Y RMS: X
Dyer: N Bawden: Y Feinberg: Y Ginder: Y Burke et al.: X
Brooks: O Gabriel: Y DECLISP: Y Steele: N Dill: X
Scherlis: - Pitman: Y Anderson: Y
Fahlman: Whatever is done about global vars, global constants should be the
same. I oppose option 3 or any plan to make them look syntactically
different.
Moon: I like to use the stars to mean "someone may bind this" rather than
"don't use this as a local variable name", which is why I voted no on
putting stars around constants. However, others might disagree with me
and I will defer to the majority. I do think stars around variable names
are important.
12. Shall a checking form CHECK-TYPE be introduced as described below?
(y) yes (n) no
Issue 12: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: - Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: Y Anderson: Y
13. Shall a checking form CHECK-SUBSEQUENCE be introduced as described below?
(y) yes (n) no
Issue 13: Controversial
Hedrick: N Wholey: - Fahlman: N Weinreb: - Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: -
Dyer: N Bawden: - Feinberg: N Ginder: Y Burke et al.: N
Brooks: - Gabriel: Y DECLISP: Y Steele: Y Dill: N
Scherlis: Y Pitman: Y Anderson: Y
Feinberg: It seems like we're taking this type checking stuff a little
too far. Let the user write his own type checking code, or
make a yellow pages package called Carefully (or Lint) or
something.
Dill: There should be a succinct way about talking about the contents
of sequences, but this particular one doesn't have the right functionality.
I prefer a regular-expression notation of some form, but don't have it
well enough worked out to propose one. Lets leave it out of the language
until someone figures out how to do it well.
14. Shall the functions LINE-OUT and STRING-OUT, eliminated in November,
be reinstated?
(y) yes (n) no
Issue 14: *** Y ***
Hedrick: N Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: - Moon: - van Roggen: Y Masinter: - RMS: -
Dyer: X Bawden: - Feinberg: Y Ginder: - Burke et al.: Y
Brooks: - Gabriel: - DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: Y Anderson: -
15. Shall the REDUCE function be added as described below?
(y) yes (n) no
Issue 15: *** Y ***
Hedrick: N Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: - Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: - Anderson: N
Moon: Should the name be REDUCE, or something else? Hearn aside, the name
doesn't instantly convey to me what it does. I haven't come up with an
alternative suggestion, however.
Pitman: I have no use for this but have no strong objection.
16. Shall the Bawden/Moon solution to the "invisible block" problem
be accepted? The solution is to define (RETURN x) to mean precisely
(RETURN-FROM NIL x), and to specify that essentially all standard
iterators produce blocks named NIL. A block with a name other than
NIL cannot capture a RETURN, only a RETURN-FROM with a matching name.
(y) yes (n) no
Issue 16: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: - RMS: N
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: -
RMS: I am strongly opposed to anything that would require me to find
all the named PROGs in the Lisp machine system which have simple
RETURNs that return from them. This would make a lot of extra work
for me. Please don't impose this on me.
Dill: It seems to me that it ought to be possible to exploit lexical
scoping to solve problems like this in a more general way. If this is
possible, then this proposeal is redundant.
17. Shall the TAGBODY construct be incorporated? This expresses just
the behavior of the GO aspect of a PROG. Any atoms in the body
are not evaluated, but serve as tags that may be specified to GO.
Tags have lexical scope and dynamic extent. TAGBODY always returns NIL.
(y) yes (n) no
Issue 17: *** Y ***
Hedrick: N Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: X
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: N
Scherlis: - Pitman: Y Anderson: Y
RMS: Why must GOBODY [sic] always return NIL just because PROG does?
It is just as easy to make GOBODY return the value of the last form in
it. We can consider a PROG to expand into a GOBODY followed by a NIL.
Feinberg: A better name than TAGBODY should be found.
18. What shall be done about RESTART? The following alternatives seem to
be the most popular:
(a) Have no RESTART form.
(b) RESTART takes the name of a block. What happens when you say
(RESTART NIL) must be clarified for most iteration constructs.
(c) There is a new binding form called, say, RESTARTABLE.
Within (RESTARTABLE FOO . body), (RESTART FOO) acts as a jump
to the top of the body of the enclosing, matching RESTARTABLE form.
RESTART tags have lexical scope and dynamic extent.
Issue 18: *** A ***
Hedrick: A Wholey: A Fahlman: A Weinreb: A Killian: A
Zubkoff: A Moon: A van Roggen: A Masinter: A RMS: C
Dyer: A Bawden: A Feinberg: A Ginder: A Burke et al.: A
Brooks: A Gabriel: B DECLISP: A Steele: C Dill: X
Scherlis: - Pitman: C Anderson: A
Fahlman: I now believe that RESTART is more trouble than it is worth. I am
strongly opposed to any plan, such as option 3, that would add a RESTART
form but make it impossible to use this with the implicit block around a
DEFUN. If you have to introduce a RESTARTABLE block, you may as
well use PROG/GO.
19. Shall there be a built-in identity function, and if so, what shall it
be called?
(c) CR (i) IDENTITY (n) no such function
Issue 19: *** I ***
Hedrick: I Wholey: I Fahlman: I Weinreb: I Killian: -
Zubkoff: I Moon: I van Roggen: I Masinter: I RMS: I
Dyer: X Bawden: I Feinberg: I Ginder: I Burke et al.: I
Brooks: I Gabriel: - DECLISP: I Steele: I Dill: X
Scherlis: I Pitman: I Anderson: -
RMS: The canonical identity function is now called PROG1, but the name
IDENTITY is ok by me.
20. Shall the #*... bit-string syntax replace #"..."? That is, shall what
was before written #"10010" now be written #*10010 ?
(y) yes (n) no
Issue 20: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: X Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: N DECLISP: Y Steele: Y Dill: Y
Scherlis: Y Pitman: Y Anderson: Y
21. Which of the two outstanding array proposals (below) shall be adopted?
(s) the "simple" proposal
(r) the "RPG memorial" proposal
(m) the "simple" proposal as amended by Moon
Issue 21: *** M? ***
Hedrick: M Wholey: - Fahlman: M Weinreb: M Killian: M
Zubkoff: M Moon: M van Roggen: M Masinter: - RMS: M
Dyer: - Bawden: M Feinberg: M Ginder: M Burke et al.: M
Brooks: R Gabriel: X DECLISP: M Steele: M Dill: M
Scherlis: M Pitman: M Anderson: M
Brooks: if not "r" then I prefer "m".
Gabriel: I prefer the "RPG memorial", but I do not feel so strong
about this that I would sink the Common Lisp effort over it.
22. Shall the following proposal for the OPTIMIZE declaration be adopted?
(y) yes (n) no
Issue 22: *** Y ***
Hedrick: Y Wholey: - Fahlman: Y Weinreb: Y Killian: N
Zubkoff: Y Moon: Y van Roggen: Y Masinter: N RMS: -
Dyer: Y Bawden: - Feinberg: N Ginder: Y Burke et al.: Y
Brooks: - Gabriel: Y DECLISP: Y Steele: - Dill: X
Scherlis: N Pitman: X Anderson: X
Pitman: I would vote YES except:
The use of numbers instead of keywords bothers me. The section saying
which numbers can be which values and how those values will be interpreted
seems to FORTRANesque to me. I think these values should be just keywords
or the tight restrictions on their values should be lifted. The only use
for numbers would be to allow users a fluid range of possibilities.
Feinberg: Keywords instead of numbers would be nicer. How about
:dont-care, :low, :medium, :high?
Dill: I don't think that we need an optimize declaration in common lisp.
It's not necessary for portability, and intensely dependent on compiler
implementations. If we must have one, I strongly favor the Fahlman proposal
over proposals that would have symbolic specifications.
23. Shall it be permitted for macros calls to expand into DECLARE forms
and then be recognized as valid declarations?
This would not allows macros calls *within* a DECLARE form, only allow
macros to expand into a DECLARE form.
(y) yes (n) no
Issue 23: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: - Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
Pitman: I also support allowing multiple declare forms at the top of
a bind form. ie,
(LAMBDA (X Y) (DECLARE (SPECIAL X)) (DECLARE (SPECIAL Y))
for ease in macros. Steele's proposed evaluator did this and it wasn't
notably expensive.
24. Shall there be printer control variables ARRAY-PRINLEVEL and
ARRAY-PRINLENGTH to control printing of arrays? These would not
limit the printing of strings.
(y) yes (n) no
Issue 24: Controversial
Hedrick: N Wholey: Y Fahlman: N Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: N RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: - Gabriel: N DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: N Anderson: Y
25. Shall lambda macros, as described below, be incorporated into
the language, and if so, shall they occupy the function name space
or a separate name space?
(f) function name space (s) separate name space (n) no lambda macros
Issue 25: Controversial
Hedrick: N Wholey: - Fahlman: N Weinreb: Y Killian: F
Zubkoff: - Moon: S van Roggen: S Masinter: D RMS: S
Dyer: S Bawden: S Feinberg: N Ginder: - Burke et al.: S
Brooks: N Gabriel: F DECLISP: S Steele: N Dill: N
Scherlis: - Pitman: S Anderson: N
Fahlman: I seem to be unable to locate any explanation of why Lambda macros
are useful enough to be worth the bother. Looks like needless hair to
me, but I seem to dimly recall some arguments for why they were needed.
I'm not passionately opposed, but every page full of hairy stuff in the
manual hurts us.
Masinter: Spec here not consistent with MACROEXPAND proposal.
Feinberg: Once again, hair that I don't think needs to be standardized on.
I think most users would never need this, and perhaps a better
way to do this can be thought of.
26. Shall the floating-point manipulations described below be adopted?
(y) as described by MOON
(a) as amended (FLOAT-SIGN changed) by GLS
(n) do not adopt them
Issue 26: *** A ***
Hedrick: A Wholey: A Fahlman: A Weinreb: A Killian: A
Zubkoff: A Moon: Y van Roggen: A Masinter: - RMS: -
Dyer: - Bawden: - Feinberg: - Ginder: A Burke et al.: -
Brooks: - Gabriel: A DECLISP: A Steele: A Dill: X
Scherlis: - Pitman: - Anderson: Y
Killian: Since TRUNC was renamed TRUNCATE at the last meeting, the
FTRUNC in this proposal would have to become FTRUNCATE.
27. Shall DEFMACRO, DEFSTRUCT, and other defining forms also be
allowed to take documentation strings as possible and appropriate?
(y) yes (n) no
Issue 27: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: Y
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: Y Pitman: Y Anderson: Y
28. Shall the following proposed revision of OPEN keywords be accepted?
(y) yes (n) no
Issue 28: *** Y ***
Hedrick: Y Wholey: Y Fahlman: Y Weinreb: Y Killian: Y
Zubkoff: Y Moon: Y van Roggen: Y Masinter: Y RMS: -
Dyer: Y Bawden: Y Feinberg: Y Ginder: Y Burke et al.: Y
Brooks: Y Gabriel: Y DECLISP: Y Steele: Y Dill: X
Scherlis: - Pitman: X Anderson: Y
DECLISP: Either READ-ALTER, READ-WRITE OR UPDATE should replace the :OVERWRITE
keyword for :DIRECTION. Overwrite suggests that an existing file will be
destroyed by having new data written into the same space.
-------