>>> Marcus Harnisch <marcus.harnisch@...> seems to think that:
>Now that I was able to play with Wisent over the Holidays, I feel more
>comfortable using it. Now I have a real question. I guess we briefly
>talked about that before in a different context.
>Is it possible to implement the following Bovine example in Wisent?
>| If we specify our token in this way:
>| %token MOOSE symbol "moose"
>| find_a_moose: MOOSE
>| then `MOOSE' will match the string "moose" explicitly, but it won't
>| do so at the lexical level, allowing use of the text "moose" in other
>| forms of regular expressions.
>It doesn't seem to be the possible using this for instance:
>%token <symbol> RADIX "radix"
When you use the above form, "radix" is matched as a lexical symbol.
When you use the form:
%token RADIX "radix"
then "radix" is now identified as a keyword. Keywords are created by
the lexical analyzer in a special way and can have properties. The
previous type is still a symbol that happens to match the string
"radix". The distinction makes more sense inside the parser
architecture where the match occurs in different places. In
particular, you cannot have a keyword with punctuation syntax, so you
need to use a form such as:
%token <punctuation> SQUIGGLE "~"
to do matching. Both cases are compatible between both types of
parser generators (bovine and wisent.)
The example you cite for the bovine parser is not a feature of the
wisent parser because it is non-standard in the realm of parser
generators. (Mixing lexical and semantic logic together, that is.)
If you need to do something like this old bovine example:
pre-moose : symbol "^moose" ;
post-moose : symbol "moose$" ;
then you should write a lexical analyzer like this:
"Identify different moosey symbols."
(semantic-lex-token 'pre-moose start (point)))))
for each such special symbol. You then need to sort your analyzer as
order is important.
David is planning on some additional lex/wisent enhancements and may
have some additional advice for after beta2 as the specific nature of
these difference may be slightly different.
>In the course of my experiments I came across a situation where I
>apparently hit the limits of LALR(1) (see Bison manual section
>"Mysterious Reduce/Reduce Conflicts"). I had to come up with an ugly
>lexer extension, which probably doesn't even work for all pathologic
>cases. Are there any plans to implement more complex parser
David can answer this best. As far as lexer hacks are concerned,
remember that Emacs is very good at matching regexps in its C code,
and parsing is slow, as it is implemented in Emacs Lisp. Take
advantage of this when it makes the most sense.
>Any plans to implement EBNF notation? I guess that would cut down
>the size of most grammars significantly and might make them arguably
[ ... ]
If someone wants to write a new parser, the framework is ready to
accept it. We even have a handy parser generator to implement it
I don't know much about EBNF.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org