[EMAIL PROTECTED]> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <[EMAIL PROTECTED]> Cc: Akim Demaille <[EMAIL PROTECTED]>, Paul Eggert <[EMAIL PROTECTED]>, [email protected] Content-Transfer-Encoding: 7bit From: Hans Aberg <[EMAIL PROTECTED]> Subject: Re: %type {...} a b c Date: Thu, 13 Jul 2006 09:04:46 +0200 To: Joel E. Denny <[EMAIL PROTECTED]> 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
