Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-09 21:20:47

Tobias Schwinger wrote:
> My point is that the utility we have here is in fact too different from 
> phoenix::switch_ to compare the two (and that boost::switch_ is not the 
> best name):
> 
> What would be the point in phoenix::switch_ if it wasn't lazy?

OK, after some thinking I managed to look beyond my own nose and figured 
out that a non-lazy phoenix::switch_ would be an expression-level switch 
(like in VHDL or Ruby) and can indeed be a practical thing.

However, I don't think that's what this library is intended for.

> 
> As Steven pointed out, overloading operator() (which is roughly what you 
> propose - just using an uglier syntax) is a rare use case. Usually we'll 
> want to feed the index to some metaprogramming machinery and instantiate 
> several high-speed dispatched control paths.
> This utility is about generating the machine code of 'switch'. It does 
> not necessarily have to mimic it's syntax!

s/it's/its/

> 
> 
>> Here's an acid test for the API -- try to implement my suggested
>> syntax on top of the "simple" API. You'll soon realize that you
>> can't 
> 
> No?! Here is how it's done:
> 
> o  Use fusion::unfused or wire up some operators to build a fusion::map 
> of constant / function object pairs, and
> 
> o  create a function object from that map that looks up the appropriate 
> function object in the map and calls it (if we want it to be non-lazily 
> evaluated) or returns it (otherwise) and is fed to 'switch_'.

Just to say it explicitly: Without using *any* PP metacode!

> 
> Please note that the reverse requires indeed to repeat the PP code.
> Also note that it would also work to implement the variant visitor.

Here's another one:

Say we have a bunch of (generic) Strategies and an Algorithm template.

Now we want to choose the an Algorithm instantiation (that is, an 
Algorithm template specialized with a Strategy) at some entry point.

We don't want dynamic calls and we want everything after the initial 
dispatch to be inlined.

Does this sound familiar? Right we just have to substitute "Strategies" 
with "Scanners" and Algorithm with "RD Parser" and "some entry point" 
with "Rule" and we're talking about Spirit's Multi Scanner Support.

A scalable solution on top of Fusion and Switch will be almost trivial.

> 
> Also also note that the 'switch_' name is obviously confusing :-).
> 
> 
>> It's not a suitable building block, like say, mpl::for_each.
> 
> No, but it fits perfectly well into the same category.

... as both are code generation constructs, for_each implementing 
sequential and switch_ (which I think should be called differently) 
selective cascading.

Regards,
Tobias