Re: C++.bison

[Hans Aberg]

At 12:42 +0200 2002/04/22, Akim Demaille wrote:
>| I merely point this out, giving you a chance to look it up.
>
>Actually, for reason of work force, I would much prefer argumented
>suggestion, as opposed to additional work.

I do not know why the C++ standard uses std::deque as defalt for
std::stack. -- But know you are aware of that fact as well, and can further
investigate, if you so want. Perhaps somebody at comp.std.c++ will know.

>| >| - It is more efficient to use only one stack (I did that in my C++
>skeleton
>| >| file).
>| >
>| >This is really a surprise to me.  I suppose it depends on how heavily
>| >you use $n etc. since you pay an additional indirection for each
>| >member.  It is definitely cuter/simpler with a single stack, but I
>| >expected it to be less efficient.
>|
>| The truth will be revealed by profiling. :-)
>
>Does this sentence implies you did not try?

I made both versions, multi and single stack versions; but I did not use a
profiler.

>| My Bison version (perhaps "HABison" :-) ) translates $n into YYVSP(yyvsp,
>| 1, yylen).
>
>We try hard to avoid relying on macros, as not all languages have
>macros.  That's one of the reason we now use M4.  But the general idea
>is exactly what we are aiming at.

M4 instead of macros is probably better.

>| Another solution might be to later on integrating M4 with Bison. -- Then
>| one lands on my ideas of a "formatter" language for Bison skeleton files.
>
>We don't _need_ to integrate it, calling it from Bison is enough.

Whatever; you develop an integrated system where M4 is called (that is, the
Bison system will not work without it).

>| For an official Bison C++ version, in view of the synchronization problem,
>| I think you may need a choice: The default would then be the true C++ IO's,
>| the C compatibility as a choice.
>
>You misunderstood my point.  Yes, we will use C++ streams.
>Nevertheless, I personally prefer printf.  These sentences are not
>related.

I am not sure what you are saying here: When you have switched to C++
streams, you will not be able to use printf. Do you not want to be able to
do that?

>| Thus user output should go to std::cout, errors to std:cerr and debugging
>| to std::clog, I believe.
>
>I don't think it is needed.  Having the logs and err synchronized is
>crucial when debugging.

They are synchronized, of course, unless you change them (they all
initially sent to the same standard output, where available).

It is in fact quite convenient to have the debugging output to clog,
because it produces a lot of output that is better sent on a file. If one
uses an interactive parser, then user output and errors go to the standard
out, and debug to the clog file. One may also want to duplicate to send
errors and user output to the clog file as well. This way the interaction
is not disturbed.

>| Under C++, it makes no difference, as there is no official C++ version out
>| there yet: So I think these can be different, keep C as it is (because it
>| works under C), and change it for C++.
>
>The point is that the internals of Bison should be language independent.

Well, the C version behavior in this respect is not official, and the
reason is so chosen is that C cannot handle the proper semantic language
constructs. So when the proper semantics becomes available under C++,
should it be shunned?

  Hans Aberg