I've fairly recently been using lemon for building several parsers in
C++ and found what I believe to be a *minimalist* means of avoiding
symbol clashes without adding bloat, or affecting C code generation.
- New '-e' command line option to define the code extension. By default
this is 'c', but
Hi all
I have been using lemon successfully to generate a parser used in a
library, and I'd like some source-level way of limiting the visibility
of some lempar symbols.
I threw together a proof of concept for a macro that can be user defined
to allow setting `static` or e.g.
`__attribute___((vis
On 12/20/19, David Given wrote:
> Does anyone know if the original source code for the lemon parser still
> exists, and if so, where to find it?
>
> The lemon.c file shipped with sqlite, which the hwaci website points me at,
> does not appear to be it --- instead it's an amalgamation of a bunch of
Does anyone know if the original source code for the lemon parser still
exists, and if so, where to find it?
The lemon.c file shipped with sqlite, which the hwaci website points me at,
does not appear to be it --- instead it's an amalgamation of a bunch of
other files, including some generated by
On 8/31/18, Warren Young wrote:
> They’re separate. Here’s the Tcl source for the bubble diagrams:
>
> https://www.sqlite.org/docsrc/file/?name=art/syntax/bubble-generator-data.tcl
>
> …and here’s the Lemon grammar for SQLite’s SQL parser:
>
> https://www.sqlite.org/src/file?name=src/parse.y
On Fri, Aug 31, 2018 at 2:59 PM Warren Young wrote:
>
> On Aug 31, 2018, at 1:55 PM, Scott Robison wrote:
> >
> > Is one generated from the other, or are they maintained separately?
>
> They’re separate. Here’s the Tcl source for the bubble diagrams:
As I suspected having looked at them in the
On Aug 31, 2018, at 1:55 PM, Scott Robison wrote:
>
> Is one generated from the other, or are they maintained separately?
They’re separate. Here’s the Tcl source for the bubble diagrams:
https://www.sqlite.org/docsrc/file/?name=art/syntax/bubble-generator-data.tcl
…and here’s the Lemon g
SQLite language as implemented uses a Lemon based parser. The syntax
diagrams are created from the bubble-generator.tcl script. Is one
generated from the other, or are they maintained separately? Is one
(or another file that I don't know exists yet) the canonical
description of the "complete" SQLit
Hi, all.
Can anybody help me with interpretation of
lemon report file?
For example, i have the next report part:
State 10:
(2) head ::= init_stmts *
init_stmts ::= init_stmts * init_stmt
init_stmt ::= * WORD init_stmt_prms SEMICOLON
WORD shi
On 4/25/17, Kelvin Sherlock wrote:
>
> I believe the issue is line 4164 which should be … = LEMON_TRUE. Currently,
> when i=0, all rules will erroneously be optimized out.
>
> 4157/* Mark rules that are actually used for reduce actions after all
> 4158** optimizations have been applie
The test case can be simplified to:
bug.lemon:
---
%include {
#include
#include
#include
#include "bug.h"
}
%code {
int main(void) {
void *pParser;
pParser = ParseAlloc(malloc);
if (!pParser) {
printf("out of memory\n");
exit(1);
This lemon bug was reported about 6 months ago:
8<
%include {
#include
#include
#include
#include "lemon-bug.h"
}
%code {
int main()
{
void *pParser;
pParser = ParseAlloc(malloc);
if (!pParser)
{
printf("out of memory\n
If you use the version of lemon.c and lempar.c in the Fossil repository for
SQLite as of 2017-04-16 20:54:23 UTC, take the following Lemon parser, compile
it, and run it, it fails with
Assertion failed: (yyruleno!=116), function yy_reduce, file
mate_grammar.c, line 2165.
(It's a gramma
On 10/8/16, Conor O'Rourke wrote:
> I believe the Lemon documentation at:
> http://www.hwaci.com/sw/lemon/lemon.html is out of date with respect to the
> default token type. If I create a parser with no token_type override, the
> default type is:
>
> #define ParseTOKENTYPE void*
>
> not int as sta
I believe the Lemon documentation at:
http://www.hwaci.com/sw/lemon/lemon.html is out of date with respect to the
default token type. If I create a parser with no token_type override, the
default type is:
#define ParseTOKENTYPE void*
not int as stated.
Thanks, Conor.
On 8/16/16, xiaobing wrote:
> In lemon.c:ReportTable() , when " Combine duplicate destructors into a
> single case ", sp2->destructor is set to 0, but later it is used in
> tranlate_code to generate destructor.
> so if you have grammar like this:
> %destructor expr_a { expr_free($$); }
> %
In lemon.c:ReportTable() , when " Combine duplicate destructors into a
single case ", sp2->destructor is set to 0, but later it is used in
tranlate_code to generate destructor.
so if you have grammar like this:
%destructor expr_a { expr_free($$); }
%destructor expr_b { expr_free($$); } //
In lemon.c:ReportTable() , when " Combine duplicate destructors into a
single case ", sp2->destructor is set to 0, but later it is used in
tranlate_code to generate destructor.
so if you have grammar like this:
%destructor expr_a { expr_free($$); }
%destructor expr_b { expr_free($$); } //
On 12/07/2016 22:01, Richard Hipp wrote:
OK. Another fix. Please try the latest trunk version.
This version works for me. Thanks.
Nick
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailma
On 7/9/16, Nick Wellnhofer wrote:
>
> This still doesn't work for me.
OK. Another fix. Please try the latest trunk version.
Note to passive readers of this thread: none of this has any impact on
SQLite. SQLite does not use the feature of the Lemon LALR(1) parser
generator that Nick is fixing.
On 08/07/2016 21:54, Richard Hipp wrote:
Please try again with the latest version of Lemon. Thanks.
This still doesn't work for me. I created a GitHub repo to demonstrate the
problem:
https://github.com/nwellnhof/lemon-bug
Nick
___
sqlite-us
On 08/07/2016 21:54, Richard Hipp wrote:
Please try again with the latest version of Lemon. Thanks.
On 7/6/16, Nick Wellnhofer wrote:
On 05/07/2016 18:12, Richard Hipp wrote:
Please try https://www.sqlite.org/src/info/2683b375ad129117 and verify
that the changes on trunk are working. Thanks
Please try again with the latest version of Lemon. Thanks.
On 7/6/16, Nick Wellnhofer wrote:
> On 05/07/2016 18:12, Richard Hipp wrote:
>> Please try https://www.sqlite.org/src/info/2683b375ad129117 and verify
>> that the changes on trunk are working. Thanks.
>
> Still doesn't work for me. The
On 05/07/2016 18:12, Richard Hipp wrote:
Please try https://www.sqlite.org/src/info/2683b375ad129117 and verify
that the changes on trunk are working. Thanks.
Still doesn't work for me. The structure of the #ifdefs in `Parse` is:
#ifdef YYERRORSYMBOL
...
#elif defined(YYNOERRORR
Please try https://www.sqlite.org/src/info/2683b375ad129117 and verify
that the changes on trunk are working. Thanks.
On 7/5/16, Nick Wellnhofer wrote:
> On 05/07/2016 17:15, Richard Hipp wrote:
>> On 7/5/16, Nick Wellnhofer wrote:
>>> No, this doesn't fix my problem. The check-in only changes
On 05/07/2016 17:15, Richard Hipp wrote:
On 7/5/16, Nick Wellnhofer wrote:
No, this doesn't fix my problem. The check-in only changes the "#ifdef
YYERRORSYMBOL" branch which I don't define. But if I add the change to the
"YYERRORSYMBOL is not defined" branch as well, everything works as
expecte
On 7/5/16, Nick Wellnhofer wrote:
> No, this doesn't fix my problem. The check-in only changes the "#ifdef
> YYERRORSYMBOL" branch which I don't define. But if I add the change to the
> "YYERRORSYMBOL is not defined" branch as well, everything works as
> expected.
Can you show me your patch, plea
No, this doesn't fix my problem. The check-in only changes the "#ifdef
YYERRORSYMBOL" branch which I don't define. But if I add the change to the
"YYERRORSYMBOL is not defined" branch as well, everything works as expected.
Thanks for the quick response!
Nick
On 05/07/2016 14:48, Richard Hipp
Please try the latest check-in
(https://www.sqlite.org/src/info/91889fa30e84760e) and let me know
whether or not it clears your problem.
On 7/5/16, Nick Wellnhofer wrote:
> Hello,
>
> I hope this is right place to report Lemon issues. I ran into a problem
> after
> upgrading to the latest version
Hello,
I hope this is right place to report Lemon issues. I ran into a problem after
upgrading to the latest version of the Lemon source code from `trunk`.
The following commit removed the initialization of `yyerrcnt` from the `Parse`
function:
http://www.sqlite.org/src/fdiff?sbs=1&v1=
On Fri, Jun 17, 2016 at 11:50:48AM -0400, Richard Hipp wrote:
> On 6/6/16, Vincent Zweije wrote:
>
> >
> > When the shiftreduce action is used in an error context,
> > such as:
> >
> >X -> alpha error.
> >
> > the adjustment is not made. This causes error handling to fail.
> >
>
> Is this pro
On 6/6/16, Vincent Zweije wrote:
>
> When the shiftreduce action is used in an error context,
> such as:
>
>X -> alpha error.
>
> the adjustment is not made. This causes error handling to fail.
>
Is this problem fixed by
https://www.sqlite.org/src/fdiff?sbs=1&v1=66a16b5e00fefff2&v2=8c4e9d851
[resent without pgp signature since i've not seen it
come back on the list or had any reaction so far]
The shiftreduce action is a shift action followed by a
reduce action. It is executed in two parts: a shift part,
shifting to an anonymous state. In this state, the state
number is actually an ind
Intro:
The shiftreduce action is a shift action followed by a
reduce action. It is executed in two parts: a shift part,
shifting to an anonymous state. In this state, the state
number is actually an indication of the reduction to perform,
independently of the lookahead symbol.
When performing the
On 4/30/16, Kelvin Sherlock wrote:
>
> Here are a couple more edge cases I noticed:
>
Thanks for the deep-diving on Lemon! All changes are now checked in.
For passive listeners - none of the bugs that Kelvin has found in
Lemon have any impact on SQLite. They only come up when using Lemon
on ot
> On Apr 29, 2016, at 7:29 AM, Richard Hipp wrote:
>
> On 4/28/16, Kelvin Sherlock wrote:
>> I believe the lemon reduce action optimizer needs to compare the codePrefix
>> and codeSuffix.
>
> Thanks for the bug report. A fix has now been checked in.
>
> --
> D. Richard Hipp
> drh at sqlite.
On 4/28/16, Kelvin Sherlock wrote:
> I believe the lemon reduce action optimizer needs to compare the codePrefix
> and codeSuffix.
Thanks for the bug report. A fix has now been checked in.
--
D. Richard Hipp
drh at sqlite.org
I believe the lemon reduce action optimizer needs to compare the codePrefix and
codeSuffix. Consider this example:
8<
%type malloc {void *}
%destructor malloc {free($$)}
%type contrived_example {int}
bug_report ::= contrived_example.
contrived_example(LHS) ::= INT INT INT. { LHS = 0; }
I am utilizing lemon in one of my Apple Store Apps. My parser works fine with
the 'old' lempar.c found in source tree TRUNK/tool/.I also found a
newer version in TRUNK/src, but when I compile myparser.c generated using this
lempar.c, I got compilation errors:test.c:376:7: error: use of
undeclar
On 4/15/15, Neo Anderson wrote:
> I am utilizing lemon in one of my Apple Store Apps. My parser works fine
> with the 'old' lempar.c found in source tree TRUNK/tool/.I also
> found a newer version in TRUNK/src, but when I compile myparser.c generated
> using this lempar.c, I got compilation errors
Hello,
Le samedi 26 juillet 2014, Richard Hipp a écrit :
>
> Historical note: I wrote Lemon back in the 80s (on a Sun3, IIRC)
You were a visionary, Lemon is probably the only viable option for a parser
generator in C/C++ at this moment.
because
> the $1,$2,$3 notation of Yacc wasn't working f
On Sat, Jul 26, 2014 at 11:10 AM, Sylvain Pointeau <
sylvain.point...@gmail.com> wrote:
> Hello,
>
> I would like to know if %wildcard is an undocumented feature on purpose, is
> this safe to use it?
>
Historical note: I wrote Lemon back in the 80s (on a Sun3, IIRC) because
the $1,$2,$3 notation
Hello,
I would like to know if %wildcard is an undocumented feature on purpose, is
this safe to use it?
if yes, could it be added in the documentation?
ps: I am pretty impressed by lemon, I am really having fun.
Best regards,
Sylvain
___
sqlite-users m
I see; well, that's unfortunate. At any rate, parsing lempar.c will
probably be much more complex than the code I have now, which solves a
simple (but common) case. Maybe I'll look into parsing lempar.c, but since
this solves my use case, I probably won't be in a hurry to do it. I
apologise to e
On Mon, Jan 7, 2013 at 4:18 PM, Tiago Rodrigues wrote:
> Oops, Dominique alerted me to the fact that the patch I included was
> stripped by the listserver... I'm including it inline, then.
>
This patch does not work in the general case. I don't doubt that it works
for your use case, but in ge
Oops, Dominique alerted me to the fact that the patch I included was
stripped by the listserver... I'm including it inline, then.
(Begin patch)
--- lemon.c2013-01-04 20:39:20 +
+++ lemon-new.c2013-01-04 23:09:59 +
@@ -109,7 +109,7 @@
void Reprint(struct lemon *);
void ReportOut
Hello, all,
First, forgive me if this is the wrong medium for submitting this, but I'm
rather new at this patch submission business. Anyway, I was using Lemon to
generate a few parsers for a program I'm writing (which uses SQLite, too,
for storage), and I noticed that the files I used to call the
On 18 Oct 2012, at 20:07, Richard Hipp wrote:
> On Thu, Oct 18, 2012 at 3:03 PM, Ben wrote:
>
>> Hi list,
>>
>> I'm having a little trouble getting my head around memory management
>> within a Lemon-generated parser. Specifically the part of the docs stating
>> when a destructor will or will
On Thu, Oct 18, 2012 at 3:03 PM, Ben wrote:
> Hi list,
>
> I'm having a little trouble getting my head around memory management
> within a Lemon-generated parser. Specifically the part of the docs stating
> when a destructor will or will not be called.
>
> For example, this is a portion of a gram
Hi list,
I'm having a little trouble getting my head around memory management within a
Lemon-generated parser. Specifically the part of the docs stating when a
destructor will or will not be called.
For example, this is a portion of a grammar based on the SQLite parse.y file:
columnName ::= n
On Sat, Jan 07, 2012 at 10:18:12AM -0500, Richard Hipp wrote:
|| On Wed, Jan 4, 2012 at 11:00 AM, Vincent Zweije wrote:
||
|| > I may have hit a bug in the lemon parser generator.
|| >
||
|| Please see if the following fix clears your problem:
||
|| http://www.sqlite.org/src/info/ce32775
On Wed, Jan 4, 2012 at 11:00 AM, Vincent Zweije wrote:
> I may have hit a bug in the lemon parser generator.
>
Please see if the following fix clears your problem:
http://www.sqlite.org/src/info/ce32775b23
>
> It looks like lookahead symbols aren't propagated properly, in some cases.
>
>
I may have hit a bug in the lemon parser generator.
It looks like lookahead symbols aren't propagated properly, in some cases.
The consequence is that in some states, valid symbols are rejected with
a syntax error.
The complete grammar can be found at
http://www.zweije.nl/~vzweije/parser.y
Hi,
I'm attempting to rewrite a buggy hand-written parser with a re2c / lemon one.
I've ran into a strange thing (which is/was actually a bug in the lexer), but I
can't determine why lemon finishes parsing, instead of throwing up a parser
error.
The stripped-down parser :
[igmar@devel native]
On Tue, Dec 07, 2010 at 08:09:53PM +0100, Begelman, Jamie wrote:
> I'm using Lemon for a non-sqlite related project and it is exiting with an
> assertion failure that I would like to understand. I have extracted the
> following small set of productions from a larger grammar. The "list"
> product
I'm using Lemon for a non-sqlite related project and it is exiting with an
assertion failure that I would like to understand. I have extracted the
following small set of productions from a larger grammar. The "list" production
happens to be the start symbol in the larger grammar.
list::= li
On Tue, Oct 12, 2010 at 6:54 PM, Vincent Adam Burns wrote:
> Is there an active maintainer for the Lemon Parser? I'm getting some
> parsing conflicts, ex:
>
> statement ::= IF LEFT_PAREN expression RIGHT_PAREN statement ELSE
> statement.
> statement ::= IF LEFT_PAREN expression RIGHT_PAREN stateme
Hi
How could I force lemon assign a specific major number to a terminal? I need
that in order to make a lemon-generated parser work together with an already
existing scanner which is not under my control, and I'd like not to fall
back to "manual" translation.
Actually "manual" translation would c
On Tue, Apr 6, 2010 at 10:40 PM, Dan Kennedy wrote:
>
> On Apr 7, 2010, at 3:23 AM, Chris verBurg wrote:
>
> > Hehe, okay, here I go. :)
> >
> >
> > I'm trying to replace an existing flex/bison parser with an re2c/lemon
> > parser, but I'm running into a methodological problem. I have a
> > hyp
On Apr 7, 2010, at 3:23 AM, Chris verBurg wrote:
> Hehe, okay, here I go. :)
>
>
> I'm trying to replace an existing flex/bison parser with an re2c/lemon
> parser, but I'm running into a methodological problem. I have a
> hypothetical grammar like this:
>
> file ::= FOO str .
> file ::= BAR s
Hehe, okay, here I go. :)
I'm trying to replace an existing flex/bison parser with an re2c/lemon
parser, but I'm running into a methodological problem. I have a
hypothetical grammar like this:
file ::= FOO str .
file ::= BAR str .
Where my keywords are FOO and BAR, and str is any ol' gene
> I'm using the Lemon parser and running into a methodological problem
that
> I
> wanted to ask the user base about. Is there a mailing list or forum
> specifically for Lemon, or is this it? :)
>
> Thanks,
> -Chris
There is no mailing list specifically for lemon. Some of us are
familiar to var
Hey guys,
I'm using the Lemon parser and running into a methodological problem that I
wanted to ask the user base about. Is there a mailing list or forum
specifically for Lemon, or is this it? :)
Thanks,
-Chris
___
sqlite-users mailing list
sqlite-use
With all the good changes to lemon recently, I thought I'd post changes that I
have made to my personal copy. One of my customers requires that I demonstrate
the version of all build tools I use at build time, so I added a few command
line parameters to help with that.
It would be nice if the
Hi,
Can I somehow simulate a syntax error from within a rule action ? This
parser looks up the token it receives, and I want to abort futher
parsing in case that the lookup fails. as if there was a syntax error in
the grammar.
Regards,
Igmr
_
On Dec 22, 2009, at 6:06 PM, Benjamin Peterson wrote:
> I'm using lemon to write a parser for a little language I'm writing.
> I'm wondering how I indicate to lemon that an error has occurred in
> processing and an exit is needed. For example, if I have:
>
> stmt(A) ::= NAME(B). { A = malloc(size
I'm using lemon to write a parser for a little language I'm writing.
I'm wondering how I indicate to lemon that an error has occurred in
processing and an exit is needed. For example, if I have:
stmt(A) ::= NAME(B). { A = malloc(sizeof(stmt)); A->name = B; }
If malloc returns NULL, what should I
2:54 PM
To: Wilson, Ron P
Cc: General Discussion of SQLite Database
Subject: Re: [sqlite] Lemon parser : compile error when using
"%token_destructor" directive
On Mon, Jun 15, 2009 at 11:42:26AM -0400, Wilson, Ron P wrote:
|| It has been a while since I used lemon (big fan thoug
|| Subject: [sqlite] Lemon parser : compile error when using
"%token_destructor" directive
||
|| Hi List,
|| This is the only place I found to ask for "lemon parser" error.
||
|| When trying to use the "%token_destructor" directive:
||
|| %include {
|| #include
|| voi
-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of ferrety ferrety
Sent: Monday, June 08, 2009 7:15 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] Lemon parser : compile error when using "%token_destructor"
directive
Hi List,
This is the only place I found
Hi List,
This is the only place I found to ask for "lemon parser" error.
When trying to use the "%token_destructor" directive:
%include {
#include
void token_dtor (struct Token * t)
{
fprintf(stderr, "In token_destructor: t -> value=%s\n", t -> value);
}
}
%token_destructor { token_dtor(
Greetings,
> Lemon does not have any feature that will provide the application with
> access to the follow-set. You could perhaps tease that informatino
> out of the "*.out" output file using a script, though.
Capital idea! That does indeed do the trick. It's straightforward to
extract the
On Aug 17, 2008, at 1:48 PM, Markus Thiele wrote:
> Greetings,
>
> I've been using Lemon for a small custom compiler project. I've used
> Bison before, and I very much prefer the way Lemon does things,
> there's
> just one feature I'm missing and haven't been able to find.
>
> Bison generates a
Greetings,
I've been using Lemon for a small custom compiler project. I've used
Bison before, and I very much prefer the way Lemon does things, there's
just one feature I'm missing and haven't been able to find.
Bison generates a human readable error message on syntax errors, and
when setting
Hi Arjen,
Thanks for the mail...I found it very helpful and i started to execute
it..I succeeded in doing it...
However i started writing a sample program for converting "Infix to
Prefix"...I am struck at this point ...so can u help me in
writing this program...
Thanks in advance
Regard
> Hi,
> Can u send me any documentation on LEMON that u have worked out.
> I have some queries also.
> 1.Does LEMON work on Windows environment?
> 2.I tried but it is not.I heard that it works on Linux environment.I am
> trying to know why not on windows...can u give me some info about it
>
> I
Hi,
Can u send me any documentation on LEMON that u have worked out.
I have some queries also.
1.Does LEMON work on Windows environment?
2.I tried but it is not.I heard that it works on Linux environment.I am
trying to know why not on windows...can u give me some info about it
I am reading the
arjunkumar keerti wrote:
>Hi,
>I found in wikipedia that Lemon parser is a part of SQLite project but i
>couldn't found any sort of information regarding to LEMON.
>Can u give me any documentation regarding how to install it and how to work
>for some programs on Lemon parser generator or any URL's
Hi,
I found in wikipedia that Lemon parser is a part of SQLite project but i
couldn't found any sort of information regarding to LEMON.
Can u give me any documentation regarding how to install it and how to work
for some programs on Lemon parser generator or any URL's that might be
helpful and can
Joe Wilson <[EMAIL PROTECTED]> wrote:
>The following grammar may be clearer to you:
Yes, it is many thanks! I believe I am making progress! At least I can see the
picture much clearer now and was able to come up with the following grammar
with just one conflict unsolved:
%left NEWLINE.
--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> > paragraph ::= PARA text.
>
> I observed the new PARA terminal token (the clear separator!?). Unfortunately
> the lexer does not
> generate such a token. Paragraph repeats are also removed.
It was just an HTML-like example. I just wanted to demonstr
Many thanks, Joe,
>Your grammar is ambiguous. The text tokens run together for
>various rules because the grammar lacks clear separators between
>them.
OK, I begin to understand. The "clear separators" need to be TERMINALs, right?
I believed that these were imlicit because there are TEXT and
--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> article ::= blocks.
>
> blocks ::= block.
> blocks ::= blocks block.
>
> block ::= heading.
> block ::= paragraph.
>
> heading ::= HEADING_START text HEADING_END.
> heading ::= HEADING_START text.
> heading ::= HEADING_START.
>
> paragraph ::= text N
I am trying to write a Wiki parser with Lemon. The Lemon features suite my
needs perfectly, but I am unfortunately stuck with the problem of parsing
conflicts.
All conflicts seem caused by repeat constructs like this:
text ::= textpiece.
text ::= text textpiece.
The complete grammar follow
Hello,
I finally find the bug. In fact that was many bugs.
- Grammar rule order.
- Input string not reseted properly.
Thank you.
David
On Nov 18, 2007 10:30 AM, Joe Wilson <[EMAIL PROTECTED]> wrote:
> It's most likely your bug. Just add some debug prints in your grammar
> and tokenizer to see
It's most likely your bug. Just add some debug prints in your grammar
and tokenizer to see what's going on.
See also: ParseTrace() in http://www.hwaci.com/sw/lemon/lemon.html
--- Téragone <[EMAIL PROTECTED]> wrote:
> I have a problem with a rule of a small calculator which accept variables :
>
>
Hello,
I have a problem with a rule of a small calculator which accept variables :
assignment(A) ::= VARIABLE(C) EQUAL expr(B).
I can set variable with simple value or expression like :
a=2
b=2+3
but when I try :
c=a+b
The result is put in variable b instead of c.
Is it my bug or a Lemon bug
For those reading this thread, I could solve my problme by using ragel
(http://www.cs.queensu.ca/~thurston/ragel/). You can define leaving
actions but also 'any change' actions. It was also easier to include
in a C++ project then lemon/flex. If my grammar becomes more
complicated, I heard it is pos
> I do not understand why lemon waits for one more token when it has
> enough information to reduce
...
>
> >>> I don't think you can. Why do you want to? Why not just go
> >>> ahead and send it the next token?
> >>>
> >> Most people find a way around this problem using white-spac
Gaspard Bucher wrote:
> PS: There is another reason, aside from aesthetics and simpler grammar
> to filter white spaces inside the tokenizer: you avoid all the parser
> conflicts you could get with "empty | or space" rules.
>
> 2007/10/24, Gaspard Bucher <[EMAIL PROTECTED]>:
>
>>> Gaspard Bucher
PS: There is another reason, aside from aesthetics and simpler grammar
to filter white spaces inside the tokenizer: you avoid all the parser
conflicts you could get with "empty | or space" rules.
2007/10/24, Gaspard Bucher <[EMAIL PROTECTED]>:
> > Gaspard Bucher <[EMAIL PROTECTED]> wrote:
> > > I
> Gaspard Bucher <[EMAIL PROTECTED]> wrote:
> > I do not understand why lemon waits for one more token when it has
> > enough information to reduce.
> >
> > I want to recognize :
> > foo = Bar()
> > when the token CLOSE_PAR is received, not when an extra token is parsed..
> >
> > How can I avoid le
Gaspard Bucher <[EMAIL PROTECTED]> wrote:
> I do not understand why lemon waits for one more token when it has
> enough information to reduce.
>
> I want to recognize :
> foo = Bar()
> when the token CLOSE_PAR is received, not when an extra token is parsed.
>
> How can I avoid lemon waiting for t
I do not understand why lemon waits for one more token when it has
enough information to reduce.
I want to recognize :
foo = Bar()
when the token CLOSE_PAR is received, not when an extra token is parsed.
How can I avoid lemon waiting for the extra token before reducing ?
Thanks for your help !
Richard,
this helped me greatly! I also derived from your example that I can use
multiple characters without conflicts like this:
---
doc ::= inline_list.
// List of allowed characters. Add more as you like.
c ::= CHAR.
c ::= SPACE.
// The c character repeat.
chars ::= c.
chars
Richard,
this helped me greatly! I also derived from your example that I can use
multiple characters without conflicts like this:
---
doc ::= inline_list.
// List of allowed characters. Add more as you like.
c ::= CHAR.
c ::= SPACE.
// The c character repeat.
chars ::= c.
chars
Ralf Junker <[EMAIL PROTECTED]> wrote:
> I am writing to ask for help about how to solve The Lemon parser conflicts.
>
> As part of a larger grammar, I am need to implement this regular expression
> in Lemon:
>
> (.+|'.+')+
>
> I tried lots of grammars, but all of them generated Lemon warning
I am writing to ask for help about how to solve The Lemon parser conflicts.
As part of a larger grammar, I am need to implement this regular expression in
Lemon:
(.+|'.+')+
I tried lots of grammars, but all of them generated Lemon warnings.
Maybe someone could have a look at the grammar bel
I had posted earlier to find if Lemon parser can be made modular. As per
previous post responses, who had advised that I look in lemon parser forum. But
I could not find a separate forum.
Please refer to the following link to get a better idea of what I'm trying to
do:
http://www.pate
Uma Krishnan uttered:
Hey, There's no need to be offensive. I did not mean to be critical. Far
from it, it does a great a job (far more than I'm capable of producing).
What I was trying to find out was, if it is possible for a .y files to
be broken such that it can be built on top on other .y
1 - 100 of 150 matches
Mail list logo