[Challenge] implementing the ambiguous operator in D

[Simen kjaeraas]

Philippe Sigaud <philippe.sigaud at gmail.com> wrote:

> But the real challenge in the SO question is the 'going back in time'  
> part,
> which I have trouble to understand : how can you modify x and y through a
> multiplication and a comparison?

I believe this to be possible, though horrible and unpleasant.
Basically, binary operations on Amb ranges create a new, temporary type.
This type keeps track of which ranges have been involved in the
operation thus far, and which operations, and at the end gives each Amb
a bool delegate( ElementType!Amb ) that has a heap copy of each other
range and evaluates the operations on each. However, this solution may
lead to inconsistent state in the combination of ranges.

Another solution is for each Amb to keep track of a 'controller', which
keeps track of the constraints given. This controller would be a
combinatorial product of references to the ranges involved. Any call to
popFront on the Amb ranges would delegate to the controller's popFront,
which would update the involved ranges. Due to the unknowability of the
number and type of ranges involved, this controller would need to be a
class. I believe, but cannot prove, that only one constraint (i.e. one
set of operations) would be feasible to keep track of in such a system,
and thus the following would not work:

auto a = amb( [1,2,3] );
auto b = amb( [1,3,6] );
auto c = amb( [3,6,9] );
a * b = 6;
a * c = 9;
assert( a == 1 );
assert( b == 6 );
assert( c == 9 );

A system based around the combinatorial range as a stand-alone, and
using filter(s) could easily do the equivalent, but would be limited in
that it would only yield one range unless given reference semantics. In
the latter case, it would function much like above, except the
controller would be a known type that the programmer him- or herself
would need to manage.

Another problem of the first system is that it has no support for
conditionals.

-- 
Simen