cl.texinfo

早期freebsd实现

@end table

@node Generalized Variables, Structures, Integer Arithmetic, Top
@section Generalized Variables

This implementation has many limitations.  Take a look to see if you
want to overcome them, the fixes might prove unnecessarily expensive for
Emacs purposes.  The ones I am clearly aware of:

@enumerate
@item
Common Lisp suggests an underlying mechanism (the setf-methods) to
implement generalized variables.  I have used ad-hoc ideas that gave me
a rather trivial implementation 
that suffers from some inflexibility.  As a result, @code{defsetf}
only admits the simplest form and there is no @code{define-modify-macro}
nor there are functions to handle the (nonexistent) setf-methods. @refill
@item
I haven't implemented (I was uninterested) @code{getf} and friends.
This shouldn't be hard.
@end enumerate

In addition to providing this mechanism, I have written @code{defsetf}s
for almost every accessor I thought of.  There is room for improvement
here, as Emacs Lisp provides many types of its own (buffers, windows,
keymaps, syntax tables, @dots{}) for which pairs of accessors and
mutators could be defined.

If you want to check whether a function has a setf-inversor, look at the
property `:setf-update-fn' of its name.  This is a characteristic of my
implementation, not mandated by Common Lisp, so you
shouldn't use it in code, but only to determine interactively what can
be setf'd.  @refill

@subsection Features Provided

@table @code
@item MACRO setf
@itemx MACRO psetf
Almost complete implementation.  @code{Setf} should handle @code{apply}
inside itself and not in a @code{defsetf}, but the difference is so
minute I feel lazy about fixing this. @code{Psetf} is the version where
the assignments occur in parallel. @refill

@item MACRO defsetf
Very sketchy implementation.  I will appreciate if somebody puts some
time in implementing the whole works of setf-methods and such.

@itemx MACRO incf
@itemx MACRO decf
The usual and standard.

@item MACRO pop
@itemx MACRO push
@itemx MACRO pushnew
Should be the usual, but I haven't had the time to test them properly. 

@item MACRO rotatef
@itemx MACRO shiftf
Very fancy.  Good for implementing history rings and such.
To swap two values, the following forms are equivalent:
@example
(rotatef a b)
(psetf a b b a)
(psetq a b b a)  ;not good for anything but variables
@end example

@end table

@node Structures, Miscellanea, Generalized Variables, Top
@section Structures

I haven't had the time to construct a complete implementation of
structures, but the part provided should stand on its own for many
purposes.  I am not supporting `BOA constructors', nor typed slots (the
@code{:type}, @code{:named} and @code{:initial-offset} options), nor
explicit representational types.  The rest should be
pretty much complete.  See the example file @file{fractions.el} for an
idea of how complete the implementation is, and for exercises. @refill

When writing these functions, I noticed I was incurring in lots of
auxiliaries.  I used dollar signs in their names, in the hope that this
could prevent clashes with user functions.  In retrospect, I should have
done it in the other sections, too.


@subsection Features Provided

@table @code
@item MACRO defstruct
Create records (a la C structs) and use them as types in your programs.
Almost completely standard.

@item make$structure$instance
This non-standard function implements most of the `guts' of the `make-'
constructors.  It can be used as an example of the pseudo
keyword-arguments.  
@end table

@node Miscellanea, To Do, Structures, Top
@section Miscellanea

@subsection Features Provided

@table @code
@item MACRO psetq
A parallel-assignments version of @code{setq}, makes the expansions of
@code{do} and @code{do*} be very similar, as they should.  Otherwise
used to swap two values, now superseded by @code{rotatef}. @refill

@item duplicate-symbols-p
@itemx pair-with-newsyms
@itemx reassemble-argslists
@itemx unzip-list
@itemx zip-lists
These are utilities I find useful when parsing a call or generating code
inside a macro.  Non standard.
@end table

@node To Do, , Miscellanea, Top
@section To Do

No doubt many people will like to extend the functionality of these
routines.  When considering doing so, please try and do it in such a way
that your implementation of a subset of the functionality of Common Lisp
is not inimical with a more extensive or more correct one.  For
definiteness, ask yourself the questions:

@itemize @bullet
@item
Will my code run under a correct implementation of Common Lisp?
@item
Will a correct implementation of Common Lisp run if my code is loaded?
@end itemize
@noindent

The first question tests the pertinence of your extensions.  The second
tries to discover ``extensions'' that prevent correct implementations of
other features.  Please tell me if you notice a case in which my code
fails to pass any of those tests.

The next subsections propose some more extensions.  I hope that they are
attempted by people learning Lisp, as a way to enhance their
understanding.  Of course, experts are also admitted. @refill

@subsection Keyword Arguments

Some effort has been done to handle keywords almost right.  For
instance, a structure constructor (@pxref{Structures}) can be invoked
with keyword arguments.

Look for the functions whose names have a @samp{klist} in them.  They
were written to facilitate parsing calls with keyword arguments, but I
haven't done a complete implementation yet.  (Note that @code{member},
@code{assoc} and perhaps some other function, have to be implemented
independently of the general framework.  More details by Email if you
want to try 
your hand at this.) @refill

@subsection Mapping Functions

There is enough support to write @code{maplist}, @code{mapl}, etc.  Emacs
Lisp already provides some of the mapping functions, the trick now is to
code the rest in a very efficient manner, so there will be an incentive
to use @code{maplist} over an explicit iteration.  I have a draft
implementation, but I don't have the time to test it now.

@subsection Complete the current implementation

Some of the features described above are only a partial implementation
of the Common Lisp features.  Things that cry for a more complete form:

@table @code
@item defsetf
Only the simplest format is supported.  The most general one is needed
too.  Also, try to get @code{define-setf-method} and
@code{get-setf-method} to work. @refill
@item define-modify-macro
Same as above.  The modify-macros provided are all ad hoc.
@item defstruct
I think my version recognizes all the options and then proceeds to
ignore most of them.  Making sure that at least good error messages are
produced would be nice.  Also, what about BOA constructors?
@end table

There are other places where your programming ingenuity would help us
all.  For instance, @code{subst}, @code{sublis} and the like could be
easily provided in the @var{lists} section.  (I haven't done it because
I wanted to have the keyword arguments stuff first.) @refill

@subsection Hash Tables

A very simple implementation of hash tables would admit only strings as
keys.  For each string and a given number of buckets (a prime is
desirable here), add the numeric values of all (or of a reasonable
subset) of the characters and assign the bucket whose index is the
remainder of the sum modulo the (prime) number of buckets.

A more convenient implementation can then be based on using
@code{prin1-to-string} on an arbitrary Lisp object and using the output
string as a key. This should make it easy to write @code{sxhash}.
Remember that one needs to ensure that @code{(equal x y)} should imply
that @w{@code{(= (sxhash x) (sxhash y))}}; and also that the keys are
state-less (so you can write them to a 
file and read them back later). @refill

Don't forget to provide a @code{defsetf} for @code{gethash}.

@subsection Packages

Packages should be easy to implement on top of a good hash table
implementation, either by using it directly or by reusing some shared
code.  Don't worry too much about efficiency: package qualification has
no run-time cost, only read- and print-time costs.

The difficult thing is to integrate it correctly.  You have to replace
the built-in functions @code{read} and @code{write}.  This is not as bad
as writing a programmable reader, but still a pain.  For starters, your
routines could remember the default definitions of the above mentioned
functions: @refill

@example
(setf def-reader  (symbol-function 'read))
(setf def-printer (symbol-function 'print))
@dots{}
@end example

And then your specialized functions could just use @code{apply} to
exercise the default ones, intercepting their activity in time to do the
package qualification.  You might have to do this to @code{prin1},
@code{prin1-to-string} and friends. @refill

@subsection Streams and Files

This is the first ``To Do'' that might require doing some C programming.
The purpose is to construct an efficient byte stream abstraction that
will allow Streams and Files to be handled.  Think of stdio, not Unix
I/O, because Emacs already runs under other operating systems.  Also,
think of doing it in a way that can be generalized easily (for instance,
streams kept in memory without a file behind, streams as an interface to
a windowing system, etc.)  Of course, the intended syntax is that of
Common Lisp.

@subsection Reader and Printer

The Emacs Lisp reader (the C function @code{Fread}) is not reentrant nor
programmable.  It could be fixed as Lisp Code, but that is probably
uglily expensive (as bad as redoing @code{eval} and @code{apply} to
support lexical scoping).  Doing this  extension is probably a bad
idea: a Common Lisp reader is incompatible with Emacs Lisp code (because
of the @samp{?\} constructions) and the most important rule to keep in
mind is that this code is running under Emacs, so the host shouldn't be
burdened too much with these emulations.  Same goes for a more complete
printer (a Common Lisp @code{format} would be incompatible with the
Emacs Lisp one). @refill

@subsection Backquote
Even if the reader is not made programmable nor reentrant, a backquoting
mechanism could come handy.  You need to study the way the current
reader does @code{quote} and hack from there.  This might be a more
worthwhile extension than the complete rewrite of the reader.

@subsection Wild Ideas
Perhaps there is a way to implement @code{block}, @code{tagbody},
@code{return} and friends in spite of the dynamic scoping of Emacs Lisp.
By this, I mean an adequate definition that preserves remotely the
original intent and still provides a sensible set of constructs.  Other
dynamically scoped Lisps have these features, so implementing them is
not necessarily impossible.

In the same spirit of these extensions would be to provide a port of
something like Flavors 
(was there a PD version from Maryland, for Franz perhaps?) and then
rephrase the language of major and minor modes in an Object Oriented
paradigm. @refill

Also, the rather gross @code{loop} macros that are out there in many
Lisp systems could be helpful to some
people (but then think of a @code{lisp-indent-hook} that handles them
properly). @refill

@bye