It happened on 21 Jun 2007, at 22:02, that Christian Schoenebeck wrote:
Es geschah am Thursday, 21. June 2007 20:18 als Hans Aberg schrieb:
How should %atomic be implemented?
How it "should" be implemented is the wrong question, or at least
addressed to
the wrong person, since I'm not familiar enough with the bison
implementation
yet. That was actually my main reason to write to this list, to
probably get
suggestions how this could fit into the current implementation of
bison.
So until somebody figure that out, it won't happen.
The rest
would be needed for implementing UTF-8 support.
No, as sequences of bytes can be put directly into the rules.
Either we have a misapprehension here, or this is exactly what I
did in my
example, so I don't get the point.
As I wrote in my reply, one can already have token character
sequences 'c_1'...'c_k' in the rules. If 'c_1...c_k' is interpreted
as 'c_1'...'c_k', then if the grammar file is written in UTF-8, the
parser will identify the UTF-8 multibyte sequence. So if the lexer
feeds that to the parser, one will get an identification. But the
error messages will currently only write out the leading byte.
Another future
application would be integrated type completion support within the
bison
skeleton parser.
I cannot parse this. Please elaborate.
With "intergrated type completion support" I mean a convenient way
for parser
developers (or actually interpreter developers) to let the user
"complete"
the current input upon the current parser state, in case there is
only one
possible shift transition, that is for highly redundant languages.
This has been discussed here. One really need LR(1) for that, because
LALR(1) compacts the states in way that the error tokens may not
appear until some reductions have been performed (And so causing the
same problem if one wants to find the completion tokens directly from
the states).
LR(1) is being implemented now, but I do not know if it is the
version that does not do this type of compaction.
Hans Aberg
_______________________________________________
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison