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

Memorial Day Ballot



1. Eliminate PARSE-NUMBER	    Okay.  Maybe a new proposal in the future.
2. LOOP => BLOCK NIL		    Yes.
3. GET-INTERNAL/REAL-TIME	    Yes, but query below.
4. Macro expansions are portable.   I'm going to reserve my vote on this one
   				    until I've studied whether any CL builtin
				    macros need to expand into imp-dep special
				    forms, at least in our implementation.
5. :allow-other-keys		    Yes.
6. (multiple-value (...nil...)...)  Yes.  Maybe not for MULTIPLE-VALUE-BIND.
7. Flush CATCH-ALL, UNWIND-ALL	    Yes.  Could be put back later if needed.
8. DEFMACRO destructuring.	    Yes.
9. PROCLAIM			    Yes.  I assume PROCLAIM is a function, not
				    a special form?
10. SIMPLE-VECTOR holds any object  Yes.
    also SIMPLE-STRING, SIMPLE-BIT-VECTOR, SIMPLE-ARRAY exist
11. FILL-POINTER		    Yes.
12. :NAMED in MAKE-ARRAY, MAKE-VECTOR	Yes.  Element 0 holds the name.
13. *READ-BASE*			    Yes.  If >10, some things that would be
				    symbols will read as numbers?
14. SUB-READ, SUB-R-D-L		    I'm reserving my vote while I study GLS's
15. *PRINfoo* => *PRINT-foo*	    Yes.
16. ~E,~F,~G like in Fortran	    Yes.  You may hear from me after I go
				    read the Fortran manual to figure out
				    how ~G differs from ~F.
17. Flush MAXPREFIX,MAXSUFFIX	    Yes.
18. | : interaction		    I'm reserving my vote while I study GLS's
19. ~:A vs NIL vs ()		    Yes.
20. APROPOS, PPRINT return NIL	    Yes.  I'd prefer no values, but NIL is okay
21. *features* are keywords	    Neutral.

---
3. How does GET-REAL-TIME differ from GET-UNIVERSAL-TIME?
How are GET-INTERNAL-TIME and GET-REAL-TIME supposed to be used?  Are
they intended for user-interface purposes, in which case they should be
in fairly coarse units, such as seconds, or are they intended for metering
purposes, in which case they should be in rather fine units (same order
of magnitude as the instruction-processing time of the machine, so that
small changes in the performance of a function are visible)?  How is the
conflict between trying to keep these numbers small, so that they are
fixnums and arithmetic on them does not noticeably interfere with the
performance of the program being measured, and trying to make them well
behaved numbers that don't "wrap around" to be resolved?  Or are all
such issues supposed to be taken care of by the TIME special form, in
which case I have to complain that it prints its output instead of
putting it somewhere where it can be processed by programs?  I don't
think we're prepared to design an elaborate Common Lisp instrumentation
system here, but some guidelines would be helpful.