Re: Token types with constructor

[Hans Aberg]

At 10:50 +0200 2004/09/13, Akim Demaille wrote:
> > I cannot use the Bison %union then, because of the limitation of C++ to not
> > use non-POD's in unions, but I experimented with a %type feature which does
> > not implement unions. But in this polymorphic approach I use, it turns out
> > not to be every essential, as an erroneous type operation will cause a C++
> > runtime dynamic_cast exception. But others ay want a %type feature for
> > keeping track of a static pointer.
>
>We cannot afford such a solution in Bison, for performance reasons.
>First, the copy are expensive because of the size of the stack
>members, plus the ctor they involve, and in addition dynamic_cast is
>an expensive operation.

The reason that I use this solution is not that I want to accommodate with
Bison, but that I already have a runtime system that build closures using a
C++ polymorphic class-hierarchy. I am working on a high level runtime
Prolog system that I originally translated from Haskell into C++, but now
is thoroughly rebuilt into a theorem prover using unification branching and
other less common features (so standard Prolog optimizations are of little
help). It is necessary to me to keep this high level runtime engine, so
that I can read the proofs the engine processes in order to independently
verify them for correctness.

In such a situation, your remarks are really not valid, as my runtime
system already imposes such computing time expenses.

As some discussions earlier in this thread indicated, it turns out that
under C++, one may want to use different solutions. This is not so
surprising, as C++ is a multiparadigm language, aimed at just that, provide
different programming needs.

So there will probably be different C++ solutions for Bison, at least
inofficially. This should not pose much of a problem, as it is easy to
write modified skeleton files.

So we already discussed what you speak about, a Bison static C++ type
system that avoids the kind of polymorphy I am using. But I would not help
me, as I would anyhow build my C++ runtime closures to be executed later in
the theorem proving.

>The C++ skeleton still has much to do to be really what everybody
>needs, but once its interface etc. stable, we will try to find a
>better solution, based on the ideas for Variants.  Meanwhile, it won't
>change.

So it is probably more important to concentrate on adding to Bison the
features that makes it easy for good folks to write their own skeleton
files. This makes public experimentation possible, and that feed back can
be used to write (a) C++ skelton file(s) that covers up common needs.

That is why I think one should have a &typed feayures, which differs for
%union only in that it does not impose an implementation based on C/C++
unions. This something one cannot expect in others languages as well. (For
example, I do not know if Java has union's).

> > In order to be able to write a decent C++ parser, I need essentially one
> > feature, a command
> >     %code <name> {...}
> > that would put {...} into a M4 macro derived from <name>. The thing is that
> > code can under C++ put in several more places than in C, and the setup
> > should be properly be synced with Flex. This takes some experimentation to
> > do.
>
>It exists, it's called %define, but I'm not ready to open this publicly.

Good. What I think is needed are some customized versions of this %define
which will be easier (i.e., more intuitive) for users to use. A simple
abstraction might be to let this %define command define other Bison %<name>
commands. Before Bison reads the .y file, it might open a special defines
file (default %defines_file yacc). Then this file might contain commands
like
    %define code
which puts %code on the lookup table. In the subsequent reading of the .y
file, the
    %code <name> {...}
command will be recognized.

  Hans Aberg