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 
something like an abstract syntax tree. Then have several end-user APIs 
access that AST. I.e., one that traverses the tree and makes callbacks 
each node. Or one that uses an XPath-like syntax to get at certain nodes 
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 
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.


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)

Reply via email to