Boost logo

Boost :

Subject: Re: [boost] Removing Bind placeholders from the global namespace
From: Eric Niebler (eric_at_[hidden])
Date: 2009-06-14 23:10:14


Joel de Guzman wrote:
> _1 + _1 is slippery. This, IMO, cannot be a Phoenix nor Lambda,
> nor Bind expression. It has to be contaminated somehow to make
> it one. Bind has no problems with it, but I do not see any
> other solution at the moment for lambda and phoenix coexisting
> at the same time other than to allow them to keep their native
> placeholders in their own namespaces.

Here's how I see this: _1 + _1 is not a valid Bind expression AFAIK. It
*is* a valid Lambda expression and a valid Phoenix expression. My
recollection of the Phoenix review is that Phoenix would be Lambda2, and
the old Lambda would be deprecated. So _1 + _1 is a Phoenix expression,
and _1 is a Phoenix placeholder, and we leave lambda::_1 alone. Bind can
be easily updated (via is_placeholder) to do the right thing.

Sadly, that's not the end of things. If _1 is in the Phoenix domain such
that _1 + _1 and _1 + 'a' are Phoenix function objects, then in what
domain is a mixed expression such as _1 >> spirit::char_ (in principle
... I don't believe this is a valid Spirit parser, but you know what I
mean)? It can't be *both* a Phoenix expression and a Spirit parser. One
domain must dominate. And right now, Proto has no mechanism for choosing.

Perhaps the idea of Grand Unified Placeholders is unimplementable in
practice (I need to think more about this), but I do think that Bind and
Phoenix can share placeholders, and that should eliminate 90% of all
complaints going forward (once Lambda is good and deprecated).

... more rumination ...

Is _1 == _2 a valid Bind expression? If so, and if we can make the
semantics of such relational binds mean the same as the equivalent
Phoenix expressions, then really, Phoenix is just an elaboration on Bind
and these two libraries can still play nicely. I think.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk