Hello,
From a vague memory of fellow developers' experiences, I have the idea that
what version of Bison/Flex one use is significant. But perhaps that isn't
relevant anymore.
For my project, written in C++, I simply downloaded the latest versions(at
least at that time); I use Bison 2.0, and F
At 11:28 + 2005/06/13, Frans Englich wrote:
For my project, written in C++, I simply downloaded the latest versions(at
least at that time); I use Bison 2.0, and Flex 2.5.31.
Those are the latest official versions. For Bison, there is a test
version 2.0a, you may want to try out, to make su
Hello,
I have a design dilemma that will become real some time in the future, and
consider how large it is, I thought it could be a good idea to take a quick
look forward.
I am building a Bison parser for a language, or to be precise, multiple
languages which all are very similar. I have a "m
>>> "Frans" == Frans Englich <[EMAIL PROTECTED]> writes:
> My wondering is how I practically should modularize the code in order to
> efficiently support these different languages.
In the future, I would like to have something like %import in Bison,
but currently, you'll have to put everything
Hello,
In some languages there are constructs which are insignificant to the parse
tree in the same way as white space (sometimes) is. Comments is one such
example.
The Flex manual have an example on how to do it at the scanner level. Åatterns
which matches the comments, but doesn't return to
At 20:46 + 2005/06/13, Frans Englich wrote:
I think I have a special scenario wrt. to comment handling: in one version of
my language, comments are allowed while in another it is not. Hence,
depending on version I want to flag the existence of comments as syntax
errors, regardless of whether
