bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trying out the c++ parser skeleton / b4_post_prologue


From: Anthony Heading
Subject: Re: trying out the c++ parser skeleton / b4_post_prologue
Date: Thu, 13 Jul 2006 09:34:55 -0400
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

Akim Demaille wrote:

But I can't see elegant means to achieve this.
[...]
What do you propose?

Well, as you mention below, I was thinking of an approach where
the semantic action code is created as a member function of
a user class.  But I would concur it comes with problems of
its own and might be inelegant, even if the end result would
be good.

exposing implementation details.  yytname is a nice example of what,
imho, should not have been documented.  Rather, the function that is
in the documentation
[...]
for (i = 0; i < YYNTOKENS; i++)
  @{
    if (yytname[i] != 0
        && yytname[i][0] == '"'
        && ! strncmp (yytname[i] + 1, token_buffer,
                      strlen (token_buffer))
        && yytname[i][strlen (token_buffer) + 1] == '"'
        && yytname[i][strlen (token_buffer) + 2] == 0)
      break;
  @}

should be provided.  The user shouldn't have to copy it, it should be
provided.

I don't agree here.  A raw array is a good interface. For example,
I want read it once and build my own hash table of tokens.  That's
hard if the data is hidden behind some arbitrary linear-scan search
interface.

I'm not eager to bind myself to implementation details.  If something
smarter than an array could be used, I'd be sad to be bound to it
because of a public or protected.

My strategy is more to look for the use cases, and them design the
interface that suits them.

Well, there's balance in all things.  In the case of the token
names and numbers, they are so fundamental that I wonder if it's
misguided to believe you can anticipate all the reasonable
use-cases with the functional interface approach you suggest
above.

To break the link with implementation internals, you could just
choose to document and make public a different array to that
which might be used internally.  I obviously don't disagree about
exposing internals, but any data tables become much less flexible
tools if the bison designers force a particular access algorithm.

Rgds

Anthony




reply via email to

[Prev in Thread] Current Thread [Next in Thread]