first-arg-only dispatch special case

For speed

call NO-APPLICABLE-METHOD in the appropriate place

Otherwise we end up with NO-PRIMARY-METHODs.  We should only compute
an EMF if there are in fact some methods, or at least that seems to be
the current behaviour of SB-MOP:COMPUTE-EFFECTIVE-METHOD-FUNCTION

add signum specializer example

note problem with :class slot

Really I want per-class allocation, not "in this class" allocation.
Achievable with a small amount of MOP, but...

gitignore fasls

deal with keyword argument checking

it was actually mostly done internally to PCL, in the effective method
computation.  However, for probably tedious historical reasons, the
way that this is actually implemented involves binding a magical
special variable at the point that the effective method form is turned
into code, which we weren't doing.  Now we are.

Include a test case.

delete stale add/remove-direct-method comment

get SPECIALIZER-DIRECT-METHODS (and -GENERIC-FUNCTIONS) right

we can do what we need by having SB-MOP:ADD-DIRECT-METHODS and
SB-MOP:REMOVE-DIRECT-METHODS maintain a per-class table, indexed by
the specializers under SB-PCL::SAME-SPECIALIZER-P, of direct methods.
This then is agnostic to whether the specializers are interned or
freshly generated.

adapt content-negotiation method combination

Make CALL-NEXT-METHOD cause an irrevocable control transfer: returning
from any primary method returns from all of them.  (Because
media-types are basically disjoint, it doesn't really make sense to
have CALL-NEXT-METHOD return).

allow digits in the media subtype

audio/mp3 might be helpful

finish implementing ACCEPT specializers

A handy example to do dispatch based on the Accept: header in
HTTP requests.  Includes a tricky method combination which
in addition can set the Content-Type: header of the response.

new protocol function GENERALIZER-EQUAL-HASH-KEY

We need arbitrary generalizer objects, not least so as to have
composable specializer functions (if we want generic functions
which can have more than one extended specializer class, we need
to be sure that our generalizers won't stomp on each other).

But that means that cacheing effective methods depends totally on
interning generalizers, which is a bit lame, unless we ask the
extended specializer implementor to provide a subkey to be used
in the key to the emf cache.  This new protocol function is a hook
for exactly that purpose.

(Minimally update the cons specializer example: it's still bad, in
that it uses symbols as the generalizer for conses, but the protocol
in principle at least doesn't leak now.)

accept-header parsing

INSERT routine to insert (and possibly modify the q of) a node

Parser using cl-ppcre, which will win few prizes for robustness but at
least gets the header as sent by Chromium on my computer right...

improve print-object for accept-tree-node

only display the (unparsed) accept string if we are printing
the root node

beginnings of content-type negotiation specializer

method combination and media-type priority computation.  Still needs
work on the accept header parser

get the protocol more right

Include some generic function arguments for specialization in protocol
functions involving generalizers.  (Otherwise there are some cases where
it's not possible to define methods not in violation of the rules about
specializers applicable to instances of not-standard classes.)

Adjust the CONS-SPECIALIZER example to suit, and include an extra test
case which shows of method-combination as well as the new ability to
have multiple applicable methods with class specializers.

fix one package export

one update -CLASS -> -GENERALIZER

test case!

Include some assertions on the behaviour of WALK

flush the EMF cache in REINITIALIZE-INSTANCE of SPECIALIZABLE-GENERIC-FUNCTION

note a fixme

handle arbitrary method combination

I think it's practically impossible to do on our own, certainly
efficiently: handling the pseudo-lisp that is an effective method is
likely to go wrong.  Piggy-back on SBCL, with
SB-PCL::MAKE-EFFECTIVE-METHOD-FUNCTION and SB-PCL::INVOKE-EMF

package fixup for cons specializers

also note a problem with the current protocol

separate out cons-specializer and walk into their own file

initial commit

Somewhat modified version of specializable.lisp from
http://www.lichteblau.com/git/?p=specializable.git
[ commit eb30d235951c3c1d128811278760f1db36cd336c ]

Lightly modified on a first read-through, mostly cosmetic though with
the innovation of the GENERALIZER concept, as in
COMPUTE-APPLICABLE-METHODS-USING-GENERALIZER and
SPECIALIZER-ACCEPTS-GENERALIZER-P.  Lots of FIXME notes for the things
that weren't trivial.