Update literate-xsl

This makes changes necessary to new ref format (which includes arity).

* src/graph.xsl: @ref function arity added
* src/preproc/expand/expand-sequence.xsl: @ref function arity added
* tools/literate-xsl: Submodule updated

src/graph.xsl

@@ -59,7 +59,7 @@
   The resulting graph will be normalized with duplicate vertices and
     edges removed,
     making it suitable for ad hoc graph generation.@c
-  @footnote{This is done by calling @ref{graph:union}.}
+  @footnote{This is done by calling @ref{graph:union#1}.}
 -->
 <function name="graph:make-from-vertices"
           as="element( preproc:sym-deps )">
@@ -208,7 +208,7 @@
   Graph operations are usually performed on single packages,
     but it is occionally necessary to traverse packages to recurisvely
     resolve dependencies.
-  @ref{graph:dep-lookup} makes this easy:
+  @ref{graph:dep-lookup#3} makes this easy:
 
   TODO: Generic graph functions.
 -->
@@ -247,10 +247,10 @@
 </function>
 
 <!--
-  @ref{graph:dep-lookup} can be used together with the convenience
+  @ref{graph:dep-lookup#3} can be used together with the convenience
-    function @ref{graph:make-from-deps} to produce a graph that
+    function @ref{graph:make-from-deps#2} to produce a graph that
     contains all dependencies for a given symbol list.
-  Used together with @ref{graph:reverse},
+  Used together with @ref{graph:reverse#1},
     a reverse dependency graph can be easily created that provides a
     useful ``used by'' relationship.
 -->
@@ -295,7 +295,7 @@
 <!--
   The provided graph lookups are constructors that use symbols to
   locate a graph.  Using partial application, they are convenient for
-  use in @ref{graph:dep-lookup} to resolve external graphs.
+  use in @ref{graph:dep-lookup#3} to resolve external graphs.
 -->
 
 <!--

src/preproc/expand/expand-sequence.xsl

@@ -38,7 +38,7 @@
   generally unnecessary.
 
   Expansion sequences are initiated by invoking
-  @ttref{eseq:expand-step} on any arbitrary node containing any number
+  @ttref{eseq:expand-step#1} on any arbitrary node containing any number
   of children to be expanded in order.  Each call will proceed one
   step (detailed herein), eventually resulting in each node expanded
   and the expansion sequence node eliminated.
@@ -191,7 +191,7 @@
   need a way for an implementation to notify us whether a node needs
   further expansion, or is ready to be hoisted.  Fortunately, we
   already have that information because of how we defined
-  @ttref{eseq:is-expandable}.  In other words, our previously declared
+  @ttref{eseq:is-expandable#1}.  In other words, our previously declared
   processing will already take care of hoisting for us when necessary,
   so we need only continue to expand nodes as necessary.
 -->
@@ -201,7 +201,7 @@
   expansions would never take place.
 
   Once expansion is complete, by the definition of
-  @ttref{eseq:is-expandable}, expansion will halt.
+  @ttref{eseq:is-expandable#1}, expansion will halt.
 -->
 <template mode="_eseq:expand" as="element()"
           match="*[ node()[1][
@@ -240,7 +240,7 @@
   yields an empty sequence, and the final template is matched.  When
   the head node @emph{is} available, it is either expandable or
   non-expandable, determined by the predicate
-  @ttref{eseq:is-expandable}.  Since the predicate returns a boolean,
+  @ttref{eseq:is-expandable#1}.  Since the predicate returns a boolean,
   it must be either @code{false()} or @code{true()}, and so it
   must satisfy either the first or second template respectively.}
 
@@ -251,7 +251,7 @@
   after all expansions are complete and the expansion sequence node
   itself is eliminated (per the final match above), then the node that
   was last expanded and hoisted will be considered to be the expansion
-  sequence by @ttref{eseq:expand-step}.  This is true, but should not
+  sequence by @ttref{eseq:expand-step#1}.  This is true, but should not
   be a problem in practice: hoisting is intended to place nodes into
   context for the caller; it is expected that the caller will
   recognize when to invoke sequence expansion (likely on a pre-defined
@@ -287,7 +287,7 @@
   function.
 
   Actual expansion is left to
-  @ref{eseq:expand-node,,@code{eseq:expand-node}}.
+  @ref{eseq:expand-node#1,,@code{eseq:expand-node#1}}.
 -->
 <function name="_eseq:expand-head" as="element()">
   <param name="eseq" as="element()" />
@@ -314,8 +314,8 @@
   expansion.
 
   Its default behavior is an important consideration: what if
-  @ttref{eseq:is-expandable} is overridden but the implementation
+  @ttref{eseq:is-expandable#1} is overridden but the implementation
-  forgets to override @ttref{eseq:expand-node}?  If the default
+  forgets to override @ttref{eseq:expand-node#1}?  If the default
   behavior were to simply echo back the node, it seems likely that we
   would never finish processing, since the very node that matched the
   predicate to begin with would remain unchanged.
@@ -334,9 +334,9 @@
   provided node.  Note that this call represents a single step in an
   expansion, so it need not result in a complete expansion; further
   processing will take place according to the result of the
-  @ttref{eseq:is-expandable} predicate.
+  @ttref{eseq:is-expandable#1} predicate.
 
-  If @ttref{eseq:is-expandable} is provided, but an override for this
+  If @ttref{eseq:is-expandable#1} is provided, but an override for this
   function is not, then the default behavior is to return a node in
   our namespace providing a description of the problem; this is to
   prevent infinite recursion/iteration.
@@ -353,7 +353,7 @@
 
 
 <!--
-  The return type of @ttref{eseq:expand-node} produces an interesting
+  The return type of @ttref{eseq:expand-node#1} produces an interesting
   concept.  Consider what may happen after an expansion:
 
   @enumerate
@@ -384,7 +384,7 @@
   continue processing; the expansion may have yielded additional
   symbols that must be added to the symbol table, for example.  The
   process will be continued on the next call to
-  @ttref{eseq:expand-step}.
+  @ttref{eseq:expand-step#1}.
 -->
 
 
@@ -396,7 +396,7 @@
   @dfn{Hoisting} is the process of moving a fully expanded head node
   out of the expansion sequence; it is the final step of the process
   for a head node and is driven wholly by the
-  @ttref{eseq:is-expandable} predicate.
+  @ttref{eseq:is-expandable#1} predicate.
 
   Unfortunately, we cannot continue processing immediately after
   hoisting for the same reasons that we cannot continue processing

tools/literate-xsl

@@ -1 +1 @@
-Subproject commit 36c9e096251f6343ddaec3a07df6211b768bd973
+Subproject commit c058e0ca1ed200cd6e3d285634dac3452d8df0a5