Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /sml/trunk/src/cm/Doc/manual.tex
ViewVC logotype

Diff of /sml/trunk/src/cm/Doc/manual.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 578, Tue Mar 14 05:16:29 2000 UTC revision 587, Thu Mar 30 09:01:52 2000 UTC
# Line 13  Line 13 
13    
14  \title{{\bf CM}\\  \title{{\bf CM}\\
15  The SML/NJ Compilation and Library Manager \\  The SML/NJ Compilation and Library Manager \\
16  {\it\small (for SML/NJ version 110.26 and later)} \\  {\it\small (for SML/NJ version 110.27 and later)} \\
17  User Manual}  User Manual}
18    
19  \setlength{\parindent}{0pt}  \setlength{\parindent}{0pt}
# Line 768  Line 768 
768  Unlike in earlier versions, it cannot be turned off since it provides  Unlike in earlier versions, it cannot be turned off since it provides
769  many of the standard pre-defined top-level bindings.  many of the standard pre-defined top-level bindings.
770    
771  The autoloader is a convenient tool for virtually ``loading'' an  The autoloader is a convenient mechanism for virtually ``loading'' an
772  entire library without incurring an undue increase in memory  entire library without incurring an undue increase in memory
773  consumption for library modules that are not actually being used.  consumption for library modules that are not actually being used.
774    
775  \subsection{Sharing of state}  \subsection{Sharing of state}
776  \label{sec:sharing}  \label{sec:sharing}
777    
778  Whenever it is legal, CM lets multiple invocations of {\tt CM.make} or  Whenever it is legal to do so, CM lets multiple invocations of {\tt
779  {\tt CM.autoload} share dynamic state created by link-time effects.  CM.make} or {\tt CM.autoload} share dynamic state created by link-time
780  Of course, sharing is not possible (and hence not ``legal'') if the  effects.  Of course, sharing is not possible (and hence not ``legal'')
781  compilation unit in question has recently been recompiled or depends  if the compilation unit in question has recently been recompiled or
782  on another compilation unit whose code has recently been re-executed.  depends on another compilation unit whose code has recently been
783  The programmer can explicitly mark certain ML files as {\em shared},  re-executed.  The programmer can explicitly mark certain ML files as
784  in which case CM will issue a warning whenever the unit's code has to  {\em shared}, in which case CM will issue a warning whenever the
785  be re-executed.  unit's code has to be re-executed.
786    
787  State created by compilation units marked as {\em private} is never  State created by compilation units marked as {\em private} is never
788  shared across multiple calls to {\tt CM.make} or {\tt CM.autoload}.  shared across multiple calls to {\tt CM.make} or {\tt CM.autoload}.
789  However, each such call incurs an associated {\em traversal} of the  To understand this behavior it is useful to introduce the notion of a
790  dependency graph, and during such a traversal each compilation unit  {\em traversal}.  A traversal is the process of traversing the
791  will be executed at most once.  In other words, the same ``program''  dependency graph on behalf of {\tt CM.make} or {\tt CM.autoload}.
792  will not see multiple instantiations of the same compilation unit  Several traversals can be executed interleaved with each other because
793  (where ``program'' refers to the code managed by one call to {\tt  a {\tt CM.autoload} traversal normally stays suspended and is
794  CM.make} or {\tt CM.autoload}).  performed incrementally driven by input from the interactive top level
795    loop.
796  As long as only {\tt CM.make} is involved, this behavior is not  
797  difficult to describe since each traversal will have completed when  As far as sharing is concerned, the rule is that during one traversal
798  the call to {\tt CM.make} returns.  However, that is not true in the  each compilation unit will be executed at most once.  In other words,
799  case of {\tt CM.autoload}.  Like {\tt CM.make}, {\tt CM.autoload}  the same ``program'' will not see multiple instantiations of the same
800  initiates a traversal. But unlike in the case of {\tt CM.make}, that  compilation unit (where ``program'' refers to the code managed by one
801  traversal remains ``suspended'' and will be performed incrementally as  call to {\tt CM.make} or {\tt CM.autoload}).  Each compilation unit
802  necessary---driven by code entered at the interactive top level.  And  will be linked at most once during a traversal and private state
803  yet, it is still the case that each compilation unit will be linked at  will not be confused with private state of other traversals that might
804  most once during this traversal and private state will not be confused  be active at the same time.
 with private state of other traversals that might be active at the  
 same time.  
805    
806  % Need a good example here.  % Need a good example here.
807    
808  \subsubsection*{Sharing annotations}  \subsubsection*{Sharing annotations}
809    
810  ML source files can be specified as being either {\em private} or {\em  ML source files can be specified as being {\em private} or {\em
811  shared}.  This is done by adding a {\em member class} specification  shared}.  This is done by adding a {\em tool parameter} specification
812  for the file in the library- or group description file (see  for the file in the library- or group description file (see
813  Section~\ref{sec:classes}).  In other words, to mark an ML file as  Section~\ref{sec:classes}).  In other words, to mark an ML file as
814  {\em private}, follow the file name with a colon {\bf :} and the word  {\em private}, follow the file name with the word {\tt private} in
815  {\tt private}.  For {\em shared} ML files, replace {\tt private} with  parentheses.  For {\em shared} ML files, replace {\tt private} with
816  {\tt shared}.  {\tt shared}.
817    
818  An ML source file that is not annotated will typically be treated as  An ML source file that is not annotated will typically be treated as
# Line 825  Line 823 
823  \subsubsection*{Sharing with the interactive system}  \subsubsection*{Sharing with the interactive system}
824    
825  The SML/NJ interactive system, which includes the compiler, is itself  The SML/NJ interactive system, which includes the compiler, is itself
826  created by linking various libraries, and some of these libraries can  created by linking modules from various libraries. Some of these
827  also be used in user programs.  Examples are the Standard ML Basis  libraries can also be used in user programs.  Examples are the
828  Library {\tt basis.cm}, the SML/NJ library {\tt smlnj-lib.cm}, and the  Standard ML Basis Library {\tt basis.cm}, the SML/NJ library {\tt
829  ML-Yacc library {\tt ml-yacc-lib.cm}.  smlnj-lib.cm}, and the ML-Yacc library {\tt ml-yacc-lib.cm}.
830    
831  If a module from a library is used by both the interactive system and  If a module from a library is used by both the interactive system and
832  a user program running under control of the interactive system, then  a user program running under control of the interactive system, then
# Line 837  Line 835 
835  \section{Member classes and tools}  \section{Member classes and tools}
836  \label{sec:classes}  \label{sec:classes}
837    
838  In addition to using existing ML source files, CM can also invoke  Most members of groups and libraries are either plain ML files or
839  tools that generate ML source code.  Examples are  other description files.  However, it is possible to incorporate other
840  program-generating programs such as ML-Yacc~\cite{tarditi90:yacc} or  types of files---as long as their contents can in some way be expanded
841  ML-Lex~\cite{appel89:lex}, literate programming tools like  into ML code or CM descriptions.  The expansion is carried out by CM's
842  noweb~\cite{ramsey:simplified}, but also more generic ``generators''  {\it tools} facility.
843  such as the checkout program {\bf co} for RCS archives.  
844  (Currently, CM knows ML-Yacc, ML-Lex, and ML-Burg, but other tools can  CM maintains an internal registry of {\em classes} and associated {\em
845  be added easily.)  rules}.  Each class represents the set of source files that its
846    corresponding rule is applicable to.  For example, the class {\tt
847  Typically, CM determines which tool to use by looking at clues like  mlyacc} is responsible for files that contain input for the parser
848  the file name suffix.  However, it is also possible to explicitly tell  generator ML-Yacc~\cite{tarditi90:yacc}.  The rule for {\tt mlyacc}
849  CM which tool to use by specifying the {\em member class} of the  takes care of expanding an ML-Yacc specifications {\tt foo.grm} by
850  source in the description file.  For this, the file name is followed  invoking the auxiliary program {\tt ml-yacc}.  The resulting ML files
851  by a colon {\bf :} and the name of the member class.  Class names are  {\tt foo.grm.sig} and {\tt foo.grm.sml} are then used as if their
852  case-insensitive.  names had directly been specified in place of {\tt foo.grm}.
853    
854    CM knows a small number of built-in classes.  In many situations these
855    classes will be sufficient, but in more complicated cases it may be
856    worthwhile to add a new class.  Since class rules are programmed in
857    ML, adding a class is not as simple a matter as writing a rule for
858    {\sc Unix}' {\tt make} program~\cite{feldman79}.  Of course,
859    using ML has also advantages because it keeps CM extremely flexible in
860    what rules can do.  Moreover, it is not necessary to learn yet another
861    ``little language'' in order to be able to program CM's tool facility.
862    
863    When looking at the member of a description file, CM determines which
864    tool to use by looking at clues like the file name suffix.  However,
865    it is also possible to specify the class of a member explicitly.  For
866    this, the member name is followed by a colon {\bf :} and the name of
867    the member class.  All class names are case-insensitive.
868    
869  In addition to genuine tool classes, there are a few member classes  In addition to genuine tool classes, there are two member classes
870  that refer to facilities internal to CM: {\tt sml} is the class of  that refer to facilities internal to CM: {\tt sml} is the class of
871  ordinary ML source files without sharing annotation, {\tt shared} is  ordinary ML source files and {\tt cm} is the class of CM library or
872  the class of ML source files whose dynamic state must be shared across  group description files.
873  invocations of {\tt CM.make} or {\tt CM.autoload}, {\tt private} is  
874  the class of ML source files whose dynamic state cannot be shared  CM automatically classifies file with a {\tt .sml} or {\tt .sig}
875  across invocations of {\tt CM.make} or {\tt CM.autoload}, and {\tt cm}  suffix as ML-source, file names ending in {\tt .cm}] as CM
876  is the class of CM library or group description files.  Known tool  descriptions.
877  classes currently are {\tt mlyacc} for ML-Yacc sources, {\tt mllex}  
878  for ML-Lex sources, and {\tt mlburg} for ML-Burg  \subsection{Tool parameters}
879  sources~\cite{mlburg93}.  
880    In many cases the name of the member that caused a rule to be invoked
881  CM automatically classifies file with a {\tt .sml} or {\tt .sig} suffix  is the only input to that rule.  However, rules can be written in such
882  as (unannotated) ML-source, file names ending in {\tt .cm}] as CM  a way that they take additional parameters.  Those parameters, if
883  descriptions, {\tt .grm} or {\tt .y} files as input to ML-Yacc, {\tt  present, must be specified in the CM description file between
884  .lex} or {\tt .l} as input to ML-Lex, and file names ending in {\tt  parentheses following the name of the member and the optional member
885  .burg} as ML-Burg specifications.  class.
886    
887    As far as CM's core tool mechanism is concerned, tool parameters are
888    uninterpreted---they are just list of strings.  Each rule is
889    responsible for assigning meaning to its own parameters.
890    
891    The {\tt sml} class accepts one parameter which must be either the
892    word {\tt shared} or the word {\tt private}.  If {\tt shared} is
893    specified, then dynamic state created by the compilation unit at
894    link-time must be shared across invocations of {\tt CM.make} or {\tt
895    CM.autoload}.  As explained earlier (Section~\ref{sec:sharing}), the
896    {\tt private} annotation means that dynamic state cannot be shared
897    across such calls to {\tt CM.make} or {\tt CM.autoload}.
898    
899    The {\tt cm} class does not accept any parameters.
900    
901    \subsection{Built-in tools}
902    
903    \subsubsection*{The ML-Yacc tool}
904    
905    The ML-Yacc tool is responsible for files that are input to the
906    ML-Yacc parser generator.  Its class name is {\tt mlyacc}.  Recognized
907    file name suffixes are {\tt .grm} and {\tt .y}.  For a source file
908    $f$, the tool produces two targets $f${\tt .sig} and $f${\tt .sml},
909    both of which are always treated as ML source files.  Parameters are
910    passed on without change to the $f${\tt .sml} file but not to the
911    $f${\tt .sig} file.
912    
913    The tool invokes the {\tt ml-yacc} command if the targets are
914    ``outdated''.  A target is outdated if it is missing or older than the
915    source.  Unless anchored using the path anchor mechanism (see
916    Section~\ref{sec:anchors}), the command {\tt ml-yacc} will be located
917    using the operating system's path search mechanism (e.g., the {\tt
918    \$PATH} environment variable).
919    
920    \subsubsection*{ML-Lex}
921    
922    The ML-Lex tool governs files that are input to the ML-Lex lexical
923    analyzer generator~\cite{appel89:lex}.  Its class name is {\tt mllex}.
924    Recognized file name suffixes are {\tt .lex} and {\tt .l}.  For a
925    source file $f$, the tool produces one targets $f${\tt .sml} which
926    will always be treated as ML source code.  Tool parameters are passed
927    on without change to that file.
928    
929    The tool invokes the {\tt ml-lex} command if the target is outdated
930    (just like in the case of ML-Yacc).  Unless anchored using the path
931    anchor mechanism (see Section~\ref{sec:anchors}), the command {\tt
932    ml-lex} will be located using the operating system's path search
933    mechanism (e.g., the {\tt \$PATH} environment variable).
934    
935    \subsubsection*{ML-Burg}
936    
937    The ML-Burg tool deals with files that are input to the ML-Burg
938    code-generater generator~\cite{mlburg93}.  Its class name is {\tt
939    mlburg}.  The only recognized file name suffix is {\tt .burg}.  For a
940    source file $f${\tt .burg}, the tool produces one targets $f${\tt
941    .sml} which will always be treated as ML source code.  Any tool
942    parameters are passed on without change to the target.
943    
944    The tool invokes the {\tt ml-burg} command if the target is outdated.
945    Unless anchored using the path anchor mechanism (see
946    Section~\ref{sec:anchors}), the command {\tt ml-lex} will be located
947    using the operating system's path search mechanism (e.g., the {\tt
948    \$PATH} environment variable).
949    
950    \subsubsection*{Shell}
951    
952    The Shell tool can be used to specify arbitrary shell commands to be
953    invoked on behalf of a given file.  The name of the class is {\tt
954    shell}.  There are no recognized file name suffixes.  This means that
955    in order to use the shell tool one must always specify the {\tt shell}
956    member class explicitly.
957    
958    The rule for the {\tt shell} class relies on tool parameters.  The
959    parameter list must be given in parentheses and follow the {\tt shell}
960    class specification.
961    
962    Consider the following example:
963    
964    \begin{verbatim}
965      foo.pp : shell (target=foo.sml options=shared
966                            /lib/cpp -P -Dbar=baz %s %t)
967    \end{verbatim}
968    
969    This member specification says that file {\tt foo.sml} can be obtained
970    from {\tt foo.pp} by running it through the C preprocessor {\tt cpp}.
971    The fact that the target file is given as a tool parameter implies
972    that the member itself is the source.  The {\tt options=} parameter
973    lists the tool parameters to be used for that target.  The command
974    line itself is given by the remaining non-keyword parameters.  Here, a
975    single {\bf \%s} is replaced by the source file name, and a single {\bf
976    \%t} is replaced by the target file name.
977    
978    In the specification one can swap the positions of source and target
979    (i.e., let member name be the target) by using a {\tt source=}
980    parameter:
981    
982    \begin{verbatim}
983      foo.sml : shell (source=foo.pp options=shared
984                             /lib/cpp -P -Dbar=baz %s %t)
985    \end{verbatim}
986    
987    Exactly one of the {\tt source=} and {\tt target=} parameters must be
988    specified; the other one is taken to be the member name itself.  The
989    target class can be given by writing a {\tt class=} parameter.
990    
991    If the member name is written using {\em native path syntax}, then the
992    source- or target-name in the parameter list is also considered to be
993    using native syntax.  Although it is possible to enclose tool
994    parameters in double quotes to avoid tokenization at delimiting
995    characters, in this case this does not have the effect of switching
996    from standard to native syntax.
997    
998    For example, if one were working on a Win32 system and the target file
999    is supposed to be in the root directory on volume {\tt D:},
1000    then one must use native syntax to write it.  One way of doing this
1001    would be:
1002    
1003    \begin{verbatim}
1004      "D:\\foo.sml" : shell (source=foo.pp options=shared
1005                                   cpp -P -Dbar=baz %s %t)
1006    \end{verbatim}
1007    
1008    \noindent As a result, {\tt foo.pp} is also interpreted as a native
1009    path name (although in this case it does not make a difference).  Had
1010    we used the {\tt target=} version from above, it would {\em not} be
1011    sufficient to do the following:
1012    
1013    \begin{verbatim}
1014      foo.pp : shell ("target=D:\\foo.sml" options=shared
1015                                     cpp -P -Dbar=baz %s %t)
1016    \end{verbatim}
1017    
1018    \noindent Since the member name {\tt foo.pp} is in standard syntax,
1019    the target name will also be interpreted this way regardless of the
1020    fact that the parameter uses double quotes.  The correct specification
1021    is:
1022    
1023    \begin{verbatim}
1024      "foo.pp" : shell ("target=D:\\foo.sml" options=shared
1025                                    cpp -P -Dbar=baz %s %t)
1026    \end{verbatim}
1027    
1028    \noindent Notice that double quotes around the target parameter are still
1029    necessary because the name contains delimiters.
1030    
1031    The shell tool invokes its command whenever the target is outdated
1032    with respect to the source.
1033    
1034    \subsubsection*{Make}
1035    
1036    The Make tool (class {\tt make}) can (almost) be seen as a specialized
1037    version of the Shell tool.  It has no source and one target (the
1038    member itself) which is always considered outdated.  As with the Shell
1039    tool, it is possible to specify target class and parameters using the
1040    {\tt class=} and {\tt options=} keyword parameters.
1041    
1042    The tool invokes the shell command {\tt make} on the target.  Unless
1043    anchored using the path anchor mechanism~\ref{sec:anchors}, the
1044    command will be located using the operating system's path search
1045    mechanism (e.g., the {\tt \$PATH} environment variable).
1046    
1047    Any tool parameters beyond the initial {\tt class=} and {\tt options=}
1048    are given as additional command line arguments to {\tt make}.  The
1049    target name is always the last command line argument.
1050    
1051    Example:
1052    
1053    \begin{verbatim}
1054      bar-grm : make (class=mlyacc -f bar-grm.mk)
1055    \end{verbatim}
1056    
1057    Here, file {\tt bar-grm} is generated (and kept up-to-date) by
1058    invoking the command:
1059    \begin{verbatim}
1060    make -f bar-grm.mk bar-grm
1061    \end{verbatim}
1062    \noindent The target file is then treated as input for {\tt ml-yacc}.
1063    
1064    Cascading Shell- and Make-tools is tricky but possible.  Here is an
1065    example that first uses Make to build {\tt bar.pp} and then filters
1066    the contens of {\tt bar.pp} through the C preprocessor to arrive at
1067    {\tt bar.sml}:
1068    
1069    \begin{verbatim}
1070      bar.pp : make (class=shell
1071                         "options=target=bar.sml cpp -Dbar=baz %s %t"
1072                     -f bar-pp.mk)
1073    \end{verbatim}
1074    
1075  \section{Conditional compilation}  \section{Conditional compilation}
1076  \label{sec:preproc}  \label{sec:preproc}
1077    
1078  In its description files, CM offers a simple conditional  In its description files, CM offers a simple conditional compilation
1079  compilation facility inspired by the pre-processor for the C  facility inspired by the pre-processor for the C language~\cite{k&r2}.
1080  language~\cite{k&r2}.  However, it is not really a pre-processor, and  However, it is not really a {\it pre}-processor, and the syntax of the
1081  the syntax of the controlling expressions is borrowed from SML.  controlling expressions is borrowed from SML.
1082    
1083  Sequences of members can be guarded by {\tt \#if}-{\tt \#endif}  Sequences of members can be guarded by {\tt \#if}-{\tt \#endif}
1084  brackets with optional {\tt \#elif} and {\tt \#else} lines in between.  brackets with optional {\tt \#elif} and {\tt \#else} lines in between.
# Line 1174  Line 1375 
1375      suffixes = ["ngrm", "ny"],      suffixes = ["ngrm", "ny"],
1376      cmdStdPath = "new-ml-yacc",      cmdStdPath = "new-ml-yacc",
1377      template = NONE,      template = NONE,
1378      extensionStyle = Tools.EXTEND [("sig", SOME "sml"),      extensionStyle =
1379                                     ("sml", SOME "sml")] }          Tools.EXTEND [("sig", SOME "sml", fn _ => NONE),
1380                          ("sml", SOME "sml", fn x => x)],
1381        dflopts = NONE }
1382  \end{verbatim}  \end{verbatim}
1383    
1384  This code can either be packaged as a CM library or entered at the  This code can either be packaged as a CM library or entered at the
# Line 1207  Line 1410 
1410    \begin{description}\setlength{\itemsep}{0pt}    \begin{description}\setlength{\itemsep}{0pt}
1411    \item[\%c] the command name (i.e., the elaboration of {\tt cmdStdPath})    \item[\%c] the command name (i.e., the elaboration of {\tt cmdStdPath})
1412    \item[\%s] the source file name in native pathname syntax    \item[\%s] the source file name in native pathname syntax
1413    \item[\%$n$] the $n$-th target file in native pathname syntax; \\    \item[\%$n$t] the $n$-th target file in native pathname syntax; \\
1414      ($n$ is specified as a decimal number, counting starts at $1$, and      ($n$ is specified as a decimal number, counting starts at $1$, and
1415      each target file name is constructed from the corresponding {\tt      each target file name is constructed from the corresponding {\tt
1416      extensionStyle} entry; if $n$ exceeds the number of targets then      extensionStyle} entry; if $n$ is $0$ (or missing), then all
1417      \%$n$ expands into itself)      targets---separated by single spaces---are inserted;
1418        if $n$ is not in the range between $0$ and the number of available
1419        targets, then {\bf \%$n$t} expands into itself)
1420      \item[\%$n$o] the $n$-th option; \\
1421        ($n$ is specified as a decimal number, counting starts at $1$;
1422         if $n$ is $0$ (or missing), then all options---separated by single
1423         spaces---are inserted;
1424         if $n$ is not in the range between $0$ and the number of available
1425         options, then {\bf \%$n$o} expands into itself)
1426    \item[\%$x$] the character $x$ (where $x$ is neither {\bf c}, nor    \item[\%$x$] the character $x$ (where $x$ is neither {\bf c}, nor
1427      {\bf s}, nor any decimal digit)      {\bf s}, {\bf t}, or {\bf o})
1428    \end{description}    \end{description}
1429  If no template string is given it defaults to {\tt "\%c \%s"}.  If no template string is given it defaults to {\tt "\%c \%s"}.
1430  \item[extensionStyle] a specification of how the names of files  \item[extensionStyle] a specification of how the names of files
# Line 1222  Line 1433 
1433  \begin{enumerate}  \begin{enumerate}
1434  \item ``{\tt Tools.EXTEND} $l$'' says that if the tool source file is  \item ``{\tt Tools.EXTEND} $l$'' says that if the tool source file is
1435  {\it file} then for each suffix {\it sfx} in {\tt (map \#1 $l$)} there  {\it file} then for each suffix {\it sfx} in {\tt (map \#1 $l$)} there
1436  will be one tool output file named {\it file}{\tt .}{\it sfx}.  will be one tool output file named {\it file}{\tt .}{\it sfx}.  The
1437  The list $l$ consists of pairs where the first component specifies the  list $l$ consists of triplets where the first component specifies the
1438  suffix string and where the second component can be used to  suffix string, where the second component optionally specifies the
1439  (optionally) specify the member class name of the corresponding  member class name of the corresponding derived file, and where the
1440  derived file.  third component is a function to calculate tool options for the
1441    target from those of the source. (Argument and result type of these
1442    functions is {\tt string list option}.)
1443  \item ``{\tt Tools.REPLACE }$(l_1, l_2)$'' specifies that given the  \item ``{\tt Tools.REPLACE }$(l_1, l_2)$'' specifies that given the
1444  base name {\it base} there will be one tool output file {\it base}{\tt  base name {\it base} there will be one tool output file {\it base}{\tt
1445  .}{\it sfx} for each suffix {\it sfx} in {\tt (map \#1 $l_2$)}.  Here,  .}{\it sfx} for each suffix {\it sfx} in {\tt (map \#1 $l_2$)}.  Here,
# Line 1236  Line 1449 
1449  as {\it base} (just like in the case of {\tt Tools.EXTEND}).  As with  as {\it base} (just like in the case of {\tt Tools.EXTEND}).  As with
1450  {\tt Tools.EXTEND}, the second components of the elements of $l_2$ can  {\tt Tools.EXTEND}, the second components of the elements of $l_2$ can
1451  optionally specify the member class name of the corresponding derived  optionally specify the member class name of the corresponding derived
1452  file.  file and the third component maps source options to target options.
1453  \end{enumerate}  \end{enumerate}
1454    \item[dflopts] an optional list of strings which is used for
1455    substituting {\bf \%$n$o} fields in {\tt template} (see above) if no
1456    options were specified.  (Note that the value of {\tt dflopts} is never
1457    passed to the option mappers in {\tt Tools.EXTEND} or {\tt
1458    Tools.REPLACE}.)
1459  \end{description}  \end{description}
1460    
1461  Less common kinds of rules can also be defined using the generic  Less common kinds of rules can also be defined using the generic

Legend:
Removed from v.578  
changed lines
  Added in v.587

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0