[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Memorial Day Ballot
- To: Fahlman @ CMU-CS-C
- Subject: Memorial Day Ballot
- From: Kent M. Pitman <KMP @ MIT-MC>
- Date: Mon, 30 May 1983 20:54:00 -0000
- Cc: Common-Lisp @ SU-AI
YES on 1-2, 4, 7-16, 19, 21.
NO on 3, 6, 18, 20.
no opinion on 5, 17.
3. No Do not add GET-INTERNAL-TIME and/or GET-REAL-TIME without
specifying the format of the time. My experience with
code that hacks times says this is frequently worthless
and often dangerous. If the units are unspecified, code
may appear to run while in fact producing bogus results.
I might accept a modified proposal where these functions
were keyworded and implementations could optionally signal
an error for keywords they didn't handle. eg,
(GET-INTERNAL-TIME :MILLISECONDS), etc.
4. Yes Constrain system-provided macros to not expand to
system-dependent special forms. Be careful to word this such
that it's understood that system-dependent macros can be part
of the expansion as long as those macros will eventually
bottom out as system-independent special forms and/or
any kind of function(s).
6. No Actually, if NIL is allowed in place of any variable to be bound or
set meaning IGNORE, I support the proposal. In the absence of such
a restriction, I am swayed by Steele's comments about irregularity.
Maclisp gets much power from allowing NIL in some forms to mean an
ignored argument, but programs which transform code suffer problems
of irregularity in what can go in which binding lists.
7. Yes In fact, if Common Lisp had primitives for creating and
manipulating processes, I would claim that CATCH-ALL and
UNWIND-ALL in some form might be needed. Perhaps, too, if
it specified the implementation of debuggers, complex
error handlers, etc. In the absence of such, however, I
have seen no valid applications for such primitives. Many internal
facilities will be implemented with CATCH/THROW and users will not
be able to recognize what kinds of tags do what things in order to
not screw themselves or thwart important system functionality.
Something like CATCH-ALL or UNWIND-ALL may be needed internally by
a given implementation, but since each implementation will almost
surely use it differently, no attempt should be made to export
or standardize this feature at this time.
8. Yes This is quite useful. Many people prefer destructuring to
&keywords. I recommend, in fact, allowing (DEFMACRO FOO (A . B) ...)
to mean (DEFMACRO FOO (A &REST B) ...) and even
(DEFMACRO FOO X ...) to mean (DEFMACRO FOO (&REST X) ...)
as I'm pretty sure the Maclisp family now allows. Maclisp even allows
(DEFMACRO FOO (&OPTIONAL ((FOO . BAR) '(A . B)) ...) ...)
to work. This, too, can be useful. Then the restriction
wouldn't be "left of &" but would rather be "any place that
is unambiguously reserved for variable names" or some such.
9. Yes This sounds harmless and might do some good.
10. Yes I probably agree with all this. A picture of the type hierarchy this
proposes would be helpful so I'd feel more sure.
12. Yes I dispute the claim that DEFSTRUCT can't already work in a site-
independent way. You could put a unique marker in slot0 of the
defstruct (eg, a gensym whose plist pointed at the real name of the
structure (which would in turn point back at the gensym)). However,
having a primitive named-array facility of some sort would be fine
15. Yes With regard to *PRINT-READABLY*, etc., the manual should give
explicit advice to users saying that they must test this flag
when writing print methods for things that print with #<...>,
otherwise this flag will be of less value.
16. Yes The change to ~G breaks a lot of code, but I suppose the eventual
result is for the better. It will certainly ease the chore of
18. No I would like to see a more coherent description of what this means
before I say yes. In general this sounds right, but I'm increasingly
bothered by the off-and-on way we seem to treat package prefixes as
either strings or symbols. There's an argument that says "...", not
|...| should be what's allowed. There are also reasons for believing
|...|:FOO should denote package "/|.../|":FOO, etc. -- at least, under
this vague proposal. I will probably vote yes on this eventually when
a complete, coherent proposal is made.
19. Yes Both styles are occasionally useful, but the only thing you can
usually guarantee the correctness of is the toplevel case. ~:A and
~:S should not be pervasive.
20. No The return value should be left undefined and implementors should
be encouraged not to return anything `big'. On the LispM, it works
well for these sorts of things to return 0 values, since they then
don't clobber the value of "*", and one can do things like
(GET 'FOO 'BAR)
(GPRINT *) ;GPRINT is a pretty printer
(CAR *) ;refers to (CAR (GET 'FOO 'BAR))
If GPRINT returned NIL, * would be clobbered with a useless value.
Specifying that these functions return no values and specifying that
this feature of the read-eval-print-loop happens might be a win.
21. Yes This problem may be more general than just FEATURES, but this is a