On Tuesday, May 29, 2001, at 11:49 AM, Paul Makepeace wrote:
> Surely it should be possible to specify the underlying *functionality*
> of the system and then have a perl source filter (or other component of
> perl's mind-addling n-tier parsing architecture) that
> rewrites/re-presents the interface in the API style du jour...
Separate the end-user API from the parser's action API. I.e., each parser
module specifies the grammar and uses a fixed style of action that
creates
something like an abstract syntax tree. Then have several end-user APIs
to
access that AST. I.e., one that traverses the tree and makes callbacks
for
each node. Or one that uses an XPath-like syntax to get at certain nodes
in
the tree. Or, in the spirit of the model-view controller, make it a tree
model and have various tree viewers (Leon will recognise this idea; as
I've
been going on about this since before the German Perl Workshop...) so you
could also 'view' the tree as an XML document, as a Data::Dumper-like
output, as a directory hierarchy (where nodes are directories and leaf
entries are files), or whatever one's sick mind can come up with.
Marcel
--
my int ($x, $y, $z, $n); $x**$n + $y**$n = $z**$n is insoluble if $n > 2;
I have discovered a truly remarkable proof which this signature is too
short to contain. (20 Aug 2001: Pierre de Fermat's 400th birthday)
