Well, actually compiling problems was not
really what I wrote for...
My concern is more that reads
that only three skeletons are supported and
glr.cc is not among them. I would love to hear
that then skeleton works well, just the doc
is out of date. Otherwise I would be interested
in details abou
Hello!
Are there other extensions for Bison/Yacc files known
than *.y and *.yy? Do Bison files have their own mime type?
Thanks in advance,
Sebastian
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Hello again!
I want to ask what the current state of the GRL C++
skeleton is. I had no trouble compiling lalr1.cc
but grl.cc seems to be different. Can anybody give
me a brief overview or a link to more information?
Thank you!
Sebastian
___
help-
Joel E. Denny wrote:
Well, if we document how the splitting is done, then I figure they can't
complain too much. I certainly don't want to see Bison parse complex C++
constructs. Let the C++ compiler catch those errors.
Wouldn't it be both easy and powerful to solve that namespace thing
usin
Joel E. Denny wrote:
If we start "parsing" namespace names, we will have a million
new questions to answer. What is the output of "::foo",
I figured the namespace name is meant to be relative to the global
namespace, so a leading "::" is implicit if not specified.
I'm not sure if this is tr
Joel E. Denny wrote:
>> (1) %prefix=abc renames function yylex to "abclex"
>> instead of putting it in namespace abc.
>
> You can write:
>
> %name-prefix="abc::"
> %define "namespace" "abc"
Works like a charm, thank you!
Sebastian
___
help-
Hello Bison people!
I noticed two things with %prefix when combined
with a C++ parser that might be bugs:
(1) %prefix=abc renames function yylex to "abclex"
instead of putting it in namespace abc.
(2) Nested namespaces do not work:
%prefix=abc::def should give
namespace abc {
