Are Google summer of code 2006 ideas still available?

Hello,

I am interested in implementing LR(1) grammar support, which
was
proposed for the 2006 edition of Google Summer of Code. Is
it posible
to request this project for this year?

Thanks,

Ramon


_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 19 Mar 2007, at 00:59, Ramón García wrote:

> I am interested in implementing LR(1) grammar support,
which was
> proposed for the 2006 edition of Google Summer of Code.
Is it posible
> to request this project for this year?

If you want to implement LR(1) in Bison, I think it is
greatly  
welcomed - probably something for Akim to answer.

The trick is to an find an efficient LR(1) implementation.
See, for  
example:
   http://pauillac.inria.fr/~fpottier/menhir/menhir.html.en

   http://dav
id.tribble.com/text/honalee.html

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

>>> "RG" == Ramón García
<ramon.garcia.fgmail.com> writes:

 > Hello,
 > I am interested in implementing LR(1) grammar support,
which was
 > proposed for the 2006 edition of Google Summer of
Code. Is it posible
 > to request this project for this year?

I suggest that you do not: Joel is already planning to work
on this,
that would be duplicate work.  But see
h
ttp://www.gnu.org/software/soc-projects/ideas.html for
other
suggestions.  If you are fluent in XML, the last one would
be
particularly useful 


_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

Akim Demaille wrote:

> I suggest that you do not: Joel is already planning to
work on this,
> that would be duplicate work.  But see
> h
ttp://www.gnu.org/software/soc-projects/ideas.html for
other
> suggestions.  If you are fluent in XML, the last one
would be
> particularly useful 

nice to see

> # One would like to be able to split the grammar in
several
> component. An "import" feature would be
acclaimed by our users.

in the list; that would be my own top feature request. I
think this is 
what Matt Cupp was asking for a few days ago. Antlr allows
grammars to 
inherit from each other; this looks like a very nice
feature, but I've 
never used it.

There's another idea for more language back-ends. Antlr has
lots of 
back-ends, maintained by different people. However, the
back-ends can be 
of low quality, and they're normally produced long after
updates to the 
base code. I'm not saying that more language support is a
bad idea, but 
I think you need to think carefully about how they're all
going to be 
maintained.

Evan


_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

Whoops, forgot to send it to the list...

---------- Forwarded message ----------
From: Matt Cupp <cuppmattgmail.com>
Date: Mar 20, 2007 11:32 AM
Subject: Re: Are Google summer of code 2006 ideas still
available?
To: Evan Lavelle <eml-bisoncyconix.com>


Yes, it was something along those lines.  I have several
files that I
currently use the same parser for and the code is very big
and ugly
looking.  I would prefer to be able to break the parsers up
based on
the type of file they are going to parse.  Problem is they
use a lot
of the same basic types inside each file type and I don't
want them
duplicated in multiple files.

Matt

On 3/20/07, Evan Lavelle <eml-bisoncyconix.com> wrote:
> Akim Demaille wrote:
> > # One would like to be able to split the grammar
in several
> > component. An "import" feature would be
acclaimed by our users.
>
> in the list; that would be my own top feature request.
I think this is
> what Matt Cupp was asking for a few days ago. Antlr
allows grammars to
> inherit from each other; this looks like a very nice
feature, but I've
> never used it.


_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 20 Mar 2007, at 11:28, Evan Lavelle wrote:

> There's another idea for more language back-ends. Antlr
has lots of  
> back-ends, maintained by different people. However, the
back-ends  
> can be of low quality, and they're normally produced
long after  
> updates to the base code. I'm not saying that more
language support  
> is a bad idea, but I think you need to think carefully
about how  
> they're all going to be maintained.

One idea I have, is to create a core language with the
possibility to  
translate into several languages. The point is that the
parser needs  
a rather limited set of language features. This is still,
though, not  
a very easy one.

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 20 Mar 2007, at 10:09, Akim Demaille wrote:

> see
> h
ttp://www.gnu.org/software/soc-projects/ideas.html for
other
> suggestions.

As for the precedences stuff, I wrote a paper (posted in the
Bison- 
Patches group) on "grammar with constraints" where
one can prohibit  
rule expansions, which generalizes most stuff I have seen,
and I show  
such a grammar can be rewritten into a CFG. So the method
depends  
only on the grammar, and not on the parsing algorithm, as
the token  
precedences that Bison now uses. And as the constraints are
imposed  
on the grammar rules, it has the locality asked for in the
link above.

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 20 Mar 2007, at 10:09, Akim Demaille wrote:

> see
> h
ttp://www.gnu.org/software/soc-projects/ideas.html for
other
> suggestions.

Wasn't there a consensus on the "labeling symbols"
stuff?

The semantic variables $k belong to the actions, so a syntax
should  
then be used to accommodate for that.

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 20 Mar 2007, at 10:09, Akim Demaille wrote:

> see
> h
ttp://www.gnu.org/software/soc-projects/ideas.html for
other
> suggestions.

As for the "Burke-Fisher Error Correction", error
recovery is poor in  
Bison because the LALR(1) algorithm may, when an error token
appears  
in the input, performed some reductions before the error is
reported.  
The same property makes it unsuitable for systems that
interactively  
reports the valid input tokens.

So I think this stuff should wait until LR(1) is in place.

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison

On 20 Mar 2007, at 10:09, Akim Demaille wrote:

>> I am interested in implementing LR(1) grammar
support, which was
>> proposed for the 2006 edition of Google Summer of
Code. Is it posible
>> to request this project for this year?
>
> I suggest that you do not: Joel is already planning to
work on this,
> that would be duplicate work.

There are more than one way to implement this, though, and
one link I  
gave implements LR(k), not only when k = 1.

   Hans Aberg




_______________________________________________
help-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison