Repository navigation
Create generic function canonicalize-declaration-specifier #1
Description
Activity
Introduction and basic use of CSTs: http://metamodular.com/concrete-syntax-tree.pdf
Even better, go to the Documentation directory, and type `make' for the most recent version.
Should we introduce another subclass for declaration specifer or just use expression-cst?
A declaration is an expression (but not a form), and in fact, a
non-null list, so the cons-cst should be used for declarations.
At the level of a CST, the only thing that the different classes can
determine is whether the expression can be taken apart (first, rest)
or not (if it is atomic). Any interpretation beyond that is outside
the scope of CSTs, and should be done by client code such as
compilers.Well, what I just wrote is not quite true.
The CST library provides tools that distinguish between forms,
declarations, documentation strings etc. in certain contexts. But it
does not provide any specific representation for those different kinds
of expressions. Maybe the need for such different representations
will come up at some later point.Not sure I understand this.
I guess information about client declarations is in the system parameter. What if an identifier is unknown? Error? Are clients expected to write methods to canonicalize their declaration specifiers or is there a default?
But I think I don't understand what this function is supposed to do, because
In addition to the definition of the generic function itself, the
enhancement consists of writing default methods (with the SYSTEM
parameter being unspecialized) for all standard Common Lisp type
identifiers.A set of tests should be written to verify that the function works
for all Common Lisp type identifiers.which makes no sense since earlier it says DECLARATION-IDENTIFIER will be TYPE, and obviously the DECLARATION-DATA can't really be specialized on. This in turn makes me wonder why types are picked off earlier than client declarations, but whatever. Also methods on type specifiers does not make sense since they can be lists.
I wrote: "A set of tests should be written to verify that the function
works for all Common Lisp type identifiers", but I meant "declaration
identifiers", not "type identifiers". Sorry.
This enhancement consists of writing a generic function named
CANONICALIZE-DECLARATION-SPECIFIER. It should take four parameters:
SYSTEM. An object representing the Common Lisp system.
DECLARATION-IDENTIFIER. A symbol that identifies what kind of
declaration specifier to be canonicalized. Methods will have EQL
specializers for this parameter. When the declaration specifier is a
type specifier, the identifier will always be the symbol TYPE. No
implicit type specifiers will ever be passed to this function.
DECLARATION-IDENTIFIER-CST. A CST that has DECLARATION-IDENTIFIER
as its associated RAW data.
DECLARATION-DATA. A CST that has the CDR of the declaration
specifier to be canonicalized as its associated RAW data.
It should return a list of CSTs representing canonicalized declaration
specifiers. A canonicalized declaration specifier is one of the
following:
plus any canonicalized declaration specifier that is specific to the
client system. The CST representing the CAR of each element of the
list should be that of the second argument to the function. The CST
representing the canonicalized declaration data should be taken from
the corresponding information in the DECLARATION-DATA CST.
In addition to the definition of the generic function itself, the
enhancement consists of writing default methods (with the SYSTEM
parameter being unspecialized) for all standard Common Lisp type
identifiers.
A set of tests should be written to verify that the function works
for all Common Lisp declaration identifiers.
[I initially accidentally wrote "type identifiers" instead of
"declaration identifiers". Sorry about that.]