(no subject)

[haberg]

address@hidden>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <address@hidden>
Cc: Akim Demaille <address@hidden>,
 Paul Eggert <address@hidden>,
 address@hidden
Content-Transfer-Encoding: 7bit
From: Hans Aberg <address@hidden>
Subject: Re: %type {...} a b c
Date: Thu, 13 Jul 2006 09:04:46 +0200
To: Joel E. Denny <address@hidden>
X-Mailer: Apple Mail (2.752.2)

On 12 Jul 2006, at 23:18, Joel E. Denny wrote:

> On Wed, 12 Jul 2006, Hans Aberg wrote:
>
>> On 12 Jul 2006, at 22:14, Joel E. Denny wrote:
>>
>>> I like the idea of making the union an implementation detail
>>> that the user doesn't have to think much about (POD issues aside).
>>
>> As a default, I guess you mean.
>
> Yes.

In a more general C++ setting, one may have to use constructs  
involving static_cast<<type>> or dynamic_cast<<type>>, where <type>  
is whatever one writes in the Bison static type system; so there  
needs to be a M4 macro bison_cast or something involving $k and  
<type>. It can then default to unions or variants or whatever. But  
the general case should, from this point of view, not be more  
difficult to handle.

The only point I know of where Bison must be programmed (part for  
having a way to trigger the Bison type system) is the rule default  
action which in the current untyped version is $$ = $1. The typed  
version is $<type>$ = $<type>1, and one will hit the need for it if C+ 
+ static typing is used. This should then make no difference whether  
variants or something else is used.

If $<type>$ = $<type>1 should be implemented into Bison, I think one  
has to collect all same <type>, and put them as a 'case' (not in  
'default') in the parser 'switch' statement. There will then be one  
'case' for each <type> used as a default action in a rule.

   Hans Aberg