The general way to use it is
opt_parser ::= #GET_OPT;
opt_parser.add_option("optionname",#ROUT(foo(_)));
opt_parser.add_option("optionname2",#ROUT(bar(_)));
To read in the options:
opt_parser.read_from_file("filename");
or
opt_parser.read("-optionname ption for the string -optionname2 etc");
This calls the bound routine associated with each option with the
value of the option (cast to one of the known types).
It recognizes bound routines of the following types
ROUT{BOOL}, ROUT{INT}, ROUT{FLT} and ROUT{STR}
Different syntaxes can be defined for the same tast by
similarly including GET_OPT and redefining the routine read_option
(which will call call_function with a
Interesting features
One issue is how much the node index stuff should be exposed
and what the naming convention should be. It is essential to expose
some of it so that algorithms that use the graph class may be
efficient.
I've used the convention that all the features with "obvious"
names (incoming outgoing etc.) take and return node arguments.
Features names with either _index and _indices as their suffix take
node index arguments.
No point in doing the $GRAPH classes until we have dispatched iters.
DIGRAPH{N} graph.sa
First cut at some graph classes.
If anybody does use this class, I'd love to get feedback. I think
there is nothing particularly controversial about the implementation,
just routine naming. Also, if anyone else has written graph classes
that are more extensive or have different functionality, I would be
very interested in using/incorporating them.
Directed graph with nodes of type N
DIGRAPH{N,E}
Edges also have additional information of type E. Includes
from DIGRAPH{N}