mirror of
git://git.code.sf.net/p/sbcl/sbcl
synced 2026-09-10 07:26:40 -04:00
304c44d731
DYNAMIC-EXTENT &REST lists. ... much as per CSR sbcl-devel 2004-03-29; ... alter listify-rest-args VOPs on non-x86 to meet the new use (don't do anything yet with the DX parameter) ... note concerns over stack manipulation in x86 DX allocation This version compiles and passes tests on x86 and alpha (modulo one unrelated bugfix, coming soon)
38 lines
1.5 KiB
Plaintext
38 lines
1.5 KiB
Plaintext
(TLA = "three letter acronym/abbreviation":-)
|
|
|
|
abbreviations we try to use pervasively in the system
|
|
|
|
As Dan Barlow pointed out long ago on the mailing list, unabbreviated
|
|
names are easier to deal with than abbreviated names, because you
|
|
never need to remember what abbreviation to use. That's true, but in a
|
|
language like Lisp which depends on compound names for important
|
|
things like structure accessors, that can lead to painful names like
|
|
MAKE-EXTERNAL-ENTRY-POINT-LAMBDA-EXPRESSION and associated indenting
|
|
confusion.
|
|
|
|
In an effort to have some of the best of both worlds, I've attempted
|
|
to impose standard abbreviations for some things. Ideally, you don't
|
|
need to remember whether to abbreviate it, or what abbreviation to
|
|
use, because it's always the same abbreviation.
|
|
|
|
Some of these already were used pretty consistently in CMU CL.
|
|
Others not so much, but in sbcl-0.7.0 I put some effort into
|
|
making them more consistent.
|
|
ARG argument
|
|
DX dynamic-extent
|
|
FUN function
|
|
GC garbage collect(ion)
|
|
N new: number, as in e.g. N-PASSES or N-WORD-BITS
|
|
old: conventional prefix for temporary variables used to
|
|
implement evaluate-only-once semantics in macros
|
|
NLE non-local entry
|
|
NLX non-local exit (in compiler IR2)
|
|
SB storage base (in compiler IR2)
|
|
SC storage class (in compiler IR2)
|
|
TN temporary name (?) (in compiler IR2)
|
|
VAR variable (in the lisp entity "noun" sense, not in the
|
|
adjectival sense)
|
|
XEP external entry point
|
|
Making them even more consistent (within the limits of ANSI and
|
|
MOP compatibility) would probably be good.
|