- svnwiki-signature-parserparameter
-
sig typeprocedure Parameter which controls if and how definition signatures are parsed during svnwiki document parsing. A definition SXML clause looks like:
(def (sig (,type ,signature . ,alist)) ,body)
where TYPE is the definition tag name (e.g. procedure) and SIGNATURE is the contents of the definition tag. This parameter affects the contents of ALIST.
A call to (svnwiki-signature-parser) takes the arguments SIGNATURE and TYPE and returns an alist of parse results, which is inserted directly into the ALIST slot. The alist associations must be proper lists, i.e. of the format ((key val) (key val)), not ((key . val) (key . val)). Currently, the only defined alist key is id, whose value is the identifier used to describe this signature. If a null alist is returned, it indicates the signature parser has punted on parsing and is leaving it up to the user.
As a special case, if this procedure returns anything other than an alist -- such as a symbol or #f -- it will be considered an identifier, and converted into the single-key alist ((id VAL)).
Typically, you would use svnwiki-signature->identifier as the value of this parameter.
This parameter defaults to (constantly '()), the null alist signalling to the SXML document user that no signature parsing was attempted during document parsing.
Examples. By default a null alist is returned, indicating no signature parsing was attempted:
(def (sig (procedure "(foo bar)")) "This foos bar.")
With the parameter set to svnwiki-signature->identifier it will extract operators from procedures and so on;
(def (sig (procedure "(foo bar)" (id foo))) "This also foos bar.")
And since the signature below can't be parsed by svnwiki-signature->identifier, an #f value is left in the id to indicate parsing was attempted but failed. The user can try to re-parse if desired.
(def (sig (procedure "(foo | bar)" (id #f))) "Tries to foo bar, but the embedded pipe confuses the reader.")