sbcl / specializable Goto Github PK
View Code? Open in Web Editor NEWgeneralized specializers work
generalized specializers work
GENERAL INFORMATION Welcome to SBCL. If you'd like to install or build the system, see the "INSTALL" file. To find out more about who created the system, see the "CREDITS" file. If you'd like information about the legalities of copying the system, see the "COPYING" file. If you'd like more information about using the system, see the man page, "sbcl.1", or the user manual in the "doc/manual" subdirectory of the distribution. (The user manual is maintained as Texinfo in the source distribution; HTML version is available for download, and "INSTALL" describes how to build the Texinfo version in HTML and PDF.) The system is a work in progress. See the "TODO" file in the source distribution for some highlights. The "BUGS" file lists current known bugs. If you'd like to make suggestions, report a bug, or help to improve the system, please send mail to one of the mailing lists: [email protected] [email protected] Note that as a spam reduction measure you must subscribe to the lists before you can post. The "HACKING" file has more details regarding hacking on and contributing to SBCL. SYSTEM-SPECIFIC HINTS for OpenBSD 6.0 and newer: SBCL must be built and run from a filesystem with the "wxallowed" mount option, such as /usr/local in the default install.
When methods with extended specializers are compiled, a style-warning
like the following is signalled:
style-warning:
can't find type for specializer (ACCEPT "image/webp") in
SB-PCL::PARAMETER-SPECIALIZER-DECLARATION-IN-DEFMETHOD.
Fixing this probably requires further changes in PCL.
I think it would be really nice if class
and quote
pattern specializers (without any further restrictions or variable bindings) were treated identically to the standard class
and eql-specializers
. This would allow the brave user to default to using pattern generic functions, and only paying for the cost when a non-trivial pattern specializer is actually included on a generic function.
As I wrote earlier, pattern-more-specific-p
establishes a partial order
on patterns which is similar to the subtype relation (See attached
figures for examples; arrows point to "more specific"). The similarity
being that the set of values matching a more specific pattern is a
subset of the values matching a less specific pattern.
Furthermore, the dispatch strategy (considering only one argument and
only pattern specializers) currently looks like this (unchanged compared
to previous email):
1 for each "specializer cluster" C (explanation below), in any order:
2 for each pattern P in C, most specific first:
3 if P matches the argument:
4 return generalizer object with
5 all specializers in the "cluster" whose
6 pattern is P or a less specific pattern
The rationale being that a single successful match should be sufficient
to determine all matching patterns (and thus accepting
pattern-specializers) as well as binding the relevant pattern variables.
This assumes that optima is smart enough to avoid unnecessary work when
sequentially trying subsequently less specific patterns (in line 2).
Now the new issue: previously, I assumed patterns would form totally
ordered "clusters" (actually connected components) under
pattern-more-specific-p
. This assumption is reflected in the algorithm
above. However, the assumption is not true (again, see attached figures,
ignore BUILT-IN-CLASS CONS
…).
A new assumption could be that patterns form connected components in a
DAG under pattern-more-specific-p
. If I'm not mistaken, a suitable
adaptation of the above algorithm would then be:
1 for each connected component C, in any order:
2 for each pattern P in C, in topological order, most specific first:
3 if P matches:
4 return generalizer object with
5 all specializers whose pattern is in the
6 transitive PATTERN-LESS-SPECIFIC-P-closure
7 of { P }
Not sorting connected components for processing should have performance
implications but should not affect the result of the computation since
the sets of matching values should be disjoint.
One potential problem is that pattern-more-specific-p
employs subtypep
when comparing (type …)
and class
patterns (see specializer-dag-2 for
excessive use of class
patterns), making the resulting ordering
I would like to resolve the tiebraker TODO as follows:
text/*
and there are specializers text/plain
and text/html
), use string<
on the specializers' media type strings.accept-tree
, have the same q
value, treat the media type that occurs earlier in the specification as preferred.I have implemented this and could push if the approach sounds reasonable.
We have two tasks at generic function invocation time:
generalizer-of-using-class gf arg
Has the advantage of simplicity
or a combination of generalizers-of-using-class gf args
and generalizer-of-using-class gf arg
Has the disadvantage of complexity but is more powerful and can be more efficient. For example, the pattern-specializer
implementation has a method which basically does (mapcar #'funcall list-of-generalizer-computation-functions args)
without generic function calls for individual arguments.
Potential improvements:
generalizer-of-using-class gf arg
to generalizer-of-using-class gf arg arg-position
to allow processing based on the position of the argument. This would allow performing processing of arguments based on their position like in the pattern-specializer
example above.generalizers-of-using-class gf args
to generalizers-of-using-class gf args num-required
to avoid consing up the list of required arguments at invocation time. This can be applied to both approaches.One solution could be a new protocol function compute-effective-arguments-function gf num-required
which would return a function with lambda-list (args generalizers)
which would in turn produce the "effective argument list" when called, for example by injecting additional arguments.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.