Re: Token types with constructor

[Hans Aberg]

At 20:54 +0200 2004/09/13, Akim Demaille wrote:
>> In such a situation, your remarks are really not valid, as my runtime
>> system already imposes such computing time expenses.
>
>Of course they are: I'm referring to Bison the package, not Bison
>as used by you.

So in the context of the Bison parser, I do not think that one single C++
solution will suffice.

>> 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.
>
>This claim does not make sense to me.  There is nothing in what I'm
>aiming
>at that would prevent your use.  Actually, I'm already making use of
>dynamic polymorphism with the stock parser.

I am rebuilding my package to see what really needed in terms of
dynamic_cast. And even though dynamic_cast is slow, it is not as slow as
operator new(). Most time in my program is not taken up to build the
closures, but in IO, the lexer, and in actual theorem proving (i.e.,
running the program built by the parser). I am told this is a common
picture for compilers. Under such circumstances, there is not so much gain
in speeding the parser up.

  Hans Aberg