Re: [boost] Re: [ANN] type_switch with pattern matching in sandbox

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-22 13:40:14

On Wed, Oct 22, 2003 at 01:49:45PM -0400, Douglas Paul Gregor wrote:
> On Wed, 22 Oct 2003, Brian McNamara wrote:
> > Oh, duh.  This is what Haskell calls "uncurry".  Wow!  Ok, so the long
> > and the short of it is that I should be writing
> >
> >    |= case<Add>( uncurry( eval(_1)+eval(_2) ) )
> 
> Ah ha! That's the right term. Even if the rest of this discussion goes
> nowhere, we should probably write uncurry... perhaps it should just be
> syntactic sugar for a tuple visitor (like variant has visitors)?

I think a "tuple visitor" and "uncurry" are two different entities.
Here is how I imagine it.  I'll use a ternary example, but of course
this generalizes to n-ary.  First, uncurry:

   tuple<A,B,C> t;

   // "===" stands for semantic equality
   uncurry3(f)(t)  ===  f( get<1>(t), get<2>(t), get<3>(t) )

I admit I don't know how "variant visitors" work.  Assuming they work
like "catamorphisms" on "sum types" in functional programming, then it
seems to me a tuple visitor should work like this:

   tuple3_visitor( f1, f2, f3, comb )(t)
      ===  comb( f1( get<1>(t) ), f2( get<2>(t) ), f3( get<3>(t) ) )

or possibly like this:

   tuple3_visitor( f1, f2, f3, comb )(t)  ===  comb( 
      make_tuple( f1( get<1>(t) ), f2( get<2>(t) ), f3( get<3>(t) ) ) )

where "comb" is unary (takes a tuple) instead of n-ary.  (Of course,
curry and uncurry can massage the interfaces in either direction.)

Note that this means that, in addition to being able to write

   |= case<Add>( uncurry2( eval(_1)+eval(_2) ) )

we could also write

   |= case<Add>( tuple2_visitor(eval,eval,plus) )

assuming that "eval" and "plus" are the right kind of entities.

Indeed, I expect the entire switch_ statement could be replaced with a
variant visitor.

-- 
-Brian McNamara (lorgon_at_[hidden])