On 7 Dec 2006, at 05:25, Joel E. Denny wrote:
Actually, names with words like "before" and "after" are not
completely
language-independent. Imagine Java where declaration order is
unimportant, and thus there's no need for this distinction.
Yeah, I had some such in mind. It might happen for
On Wed, 6 Dec 2006, Jeff Inman wrote:
> Just to chime in, then ... as with any software tool, if there are just a few
> awkward
> terms to learn, I can learn what I need to know from a manual, and re-read it
> when I have to do maintenance, until the terms just become "natural".
Yes, this is what
On Wed, 6 Dec 2006, Hans Aberg wrote:
> The problem is not that they are complicated, as they are rather
> straightforward, but eneded up with descriptions hard to understand what they
> do.
I have some ideas on how to improve it. I'll work on that later.
> When I tweaked Bison, I used names (i
On 6 Dec 2006, at 17:28, Jeff Inman wrote:
But I think it should by now put all into a C++ namespace.
Yes, but in that namespace, I'll still have parser::token::FOO,
which I feel
is unnecessarily noisy. That's the "second half" that I'd like to
work around.
I'd prefer having the yy:pars
[this came out of an off-topic question by me.]
On Dec 6, 2006, at 9:00 AM, Hans Aberg wrote:
On 6 Dec 2006, at 15:31, Jeff Inman wrote:
...is there a simple way to use a C++ skeleton but to have the token
enumerants generated directly into the std namespace?
yy::parser::token::FOO
is a mo
On 6 Dec 2006, at 15:31, Jeff Inman wrote:
...is there a simple way to use a C++ skeleton but to have the token
enumerants generated directly into the std namespace?
yy::parser::token::FOO
is a mouthful.
Why would you want that - "std" is reserved for the implementation of
the C++ compil
On Dec 6, 2006, at 2:58 AM, Joel E. Denny wrote:
On Wed, 6 Dec 2006, Hans Aberg wrote:
Potentially, but I'm not inclined to complicate the existing
directives as
we grope in the dark trying to accommodate future target
languages that we
haven't even identified yet.
This is what I am sayi
On 6 Dec 2006, at 10:58, Joel E. Denny wrote:
Potentially, but I'm not inclined to complicate the existing
directives as
we grope in the dark trying to accommodate future target
languages that we
haven't even identified yet.
This is what I am saying: you may already have done that by the
On 6 Dec 2006, at 10:56, Joel E. Denny wrote:
Wordings like:
%code {code }
Other than semantic actions, this is probably the most common
place you should
write
verbatim code for the parser implementation.
Does not really tell what the command does.
I intended it to help you remember the c
On Wed, 6 Dec 2006, Hans Aberg wrote:
> > Potentially, but I'm not inclined to complicate the existing directives as
> > we grope in the dark trying to accommodate future target languages that we
> > haven't even identified yet.
>
> This is what I am saying: you may already have done that by the
On Wed, 6 Dec 2006, Hans Aberg wrote:
> Wordings like:
>
> %code {code }
> Other than semantic actions, this is probably the most common place you should
> write
> verbatim code for the parser implementation.
>
> Does not really tell what the command does.
I intended it to help you remember the
On 5 Dec 2006, at 23:30, Joel E. Denny wrote:
The problem is that different languages use different paradigms,
and it
m,ay
not be possible to do this stuff in that context then.
Until we know what those languages are, I'm not sure how to
handle them.
So then you cannot produce a unified
I'm trying to reply to a message archived by help-bison twice but that I
never received in my inbox:
http://lists.gnu.org/archive/html/help-bison/2006-12/index.html
What's worse, my attempts to reply have been rejected as "stock spam".
So, my reply is attached.On Tue, 5 Dec 20006, Hans Aberg
On Tue, 5 Dec 2006, Hans Aberg wrote:
> On 4 Dec 2006, at 22:56, Joel E. Denny wrote:
>
> > > The problem is that different languages use different paradigms, and it
> > > m,ay
> > > not be possible to do this stuff in that context then.
> >
> > Until we know what those languages are, I'm not su
On 4 Dec 2006, at 22:59, Joel E. Denny wrote:
On Mon, 4 Dec 2006, Hans Aberg wrote:
On 4 Dec 2006, at 20:01, Joel E. Denny wrote:
Well, maybe I'm wasting your time, but I hope that helps you to
get a
better feel for the names than my original post did.
I think you need to explain these m
On 4 Dec 2006, at 22:59, Joel E. Denny wrote:
On Mon, 4 Dec 2006, Hans Aberg wrote:
On 4 Dec 2006, at 20:01, Joel E. Denny wrote:
Well, maybe I'm wasting your time, but I hope that helps you to
get a
better feel for the names than my original post did.
I think you need to explain these m
On 4 Dec 2006, at 22:56, Joel E. Denny wrote:
The problem is that different languages use different paradigms,
and it m,ay
not be possible to do this stuff in that context then.
Until we know what those languages are, I'm not sure how to handle
them.
So then you cannot produce a unified
On Mon, 4 Dec 2006, Hans Aberg wrote:
> On 4 Dec 2006, at 20:01, Joel E. Denny wrote:
>
> > Well, maybe I'm wasting your time, but I hope that helps you to get a
> > better feel for the names than my original post did.
>
> I think you need to explain these much better, simply because wordings li
On Mon, 4 Dec 2006, Hans Aberg wrote:
> The problem is that different languages use different paradigms, and it m,ay
> not be possible to do this stuff in that context then.
Until we know what those languages are, I'm not sure how to handle them.
> It might work for
> parser specific features, b
On 4 Dec 2006, at 20:01, Joel E. Denny wrote:
Well, maybe I'm wasting your time, but I hope that helps you to get a
better feel for the names than my original post did.
I think you need to explain these much better, simply because
wordings like "this is the right place to put stuff like" is
On 4 Dec 2006, at 19:33, Joel E. Denny wrote:
, but if your design is still flexible, I'd suggest
using names that are more obvious about where the code will be
generated. For example:
%header{...}
%both{...}
Or maybe:
%declare{...}
%define{...}
%both{...}
In test release 2.3a, the directi
On Mon, 4 Dec 2006, Joel E. Denny wrote:
> > , but if your design is still flexible, I'd suggest
> > using names that are more obvious about where the code will be
> > generated. For example:
Although you can read about this in the NEWS entry for 2.3a, there's a
caveat you should be aware of if
On Mon, 4 Dec 2006, Jeff Inman wrote:
> > I meant to ask: does this sound like it will address your needs?
>
> Thanks for your reply. Yes, these sound like they will more than
> solve my problem. I can use a manual (and your message) to help
> me remember which is which
Currently in CVS, I've
On Dec 2, 2006, at 2:11 PM, Joel E. Denny wrote:
On Sat, 2 Dec 2006, Joel E. Denny wrote:
On Fri, 1 Dec 2006, Jeff Inman wrote:
It seems wrong to me that the second set of "%{ ... %}", after a
"%union{
...}", should insert
into the tab.cpp file, instead of into the tab.hpp file. I want
On Sat, 2 Dec 2006, Joel E. Denny wrote:
> On Fri, 1 Dec 2006, Jeff Inman wrote:
>
> > It seems wrong to me that the second set of "%{ ... %}", after a "%union{
> > ...}", should insert
> > into the tab.cpp file, instead of into the tab.hpp file. I want to make
> > more
> > declarations
> > th
On Fri, 1 Dec 2006, Jeff Inman wrote:
> It seems wrong to me that the second set of "%{ ... %}", after a "%union{
> ...}", should insert
> into the tab.cpp file, instead of into the tab.hpp file. I want to make more
> declarations
> that depend on the type produced by the union.
I definitely ag
Hi folks,
I'm running bison 2.3 on OSX 10.4.8
It seems wrong to me that the second set of "%{ ... %}", after a "%
union{ ...}", should insert
into the tab.cpp file, instead of into the tab.hpp file. I want to
make more declarations
that depend on the type produced by the union. It seems to
27 matches
Mail list logo
