Patrick R. Michaud a écrit :
> As that's being done, I suspect we may discover a far superior
> mechanism for handling optables in general, including allowing
> multiple optables.
>
The only piece of information I could find about protoregexes was
actually STD.pm. I'm sure that I don't understand all details (in
particular, STD.pm defines precedence levels, this looks like black
magic to me for the moment), but it seems indeed that protoregexes could
do the trick.
> An intermediate answer might be to have an "is optable" trait
> for proto subs that can specify an optable to use other than
> the default.
That would be possible: if you like, I can write something for that...
(But read the following.)
> In particular, I don't want to provide too many new structures/
> features that we may want to turn around and quickly deprecate
> when protoregexes come into play
I agree with that, so it may be better to forget about this patch for
the moment.
May I just suggest that the documentation be changed to state explicitly
that only one optable is allowed? (Something like the tiny attached patch?)
--
Florian,
http://openweb.eu.org/
http://www.linux-france.org/
--- docs/pct/pct_optable_guide.pod 2008-09-17 00:14:34.000000000 +0200
+++ docs/pct/pct_optable_guide.new 2008-10-18 18:29:08.000000000 +0200
@@ -426,7 +426,7 @@
=item * How many operator tables can I use in my language?
-{{ XXX I think one only? Anybody? }}
+You can only use one optable in your grammar.
=item * How does an optable parser work?
