On Sun, Sep 5, 2010 at 12:00, Simen kjaeraas <simen.kja...@gmail.com> wrote:
> Philippe Sigaud <philippe.sig...@gmail.com> wrote:
>
> I guess the D syntax would be
>> auto x = amb([1,2,3]);
>> auto y =amb([4,5,6]);
>> x*y == 8; // forces desambiguation => the ambs explore the possibilities.
>> assert(x == amb([2]));
>> assert(y == amb([4]));
>>
>> There is only one value left, no more ambiguity.
>>
>
> But what happens in the case where there is more than one value left?
>
If I understand correctly the linked Ruby and Haskell versions, the search
stops as soon as you find a possibility. But then, I'm no pro on this.
> That's one of the reasons I feel that doing the combination, then
> filtering it, is more correct. There is also the fact that the above
> syntax does not let you call arbitrary functions in the requirements,
> something filter does.
The combining and filtering is interesting (in this case, it'd be like doing
a list comprehension).
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 did a range comprehension maybe one year ago, which would be partially
equivalent to the problem:
auto solution = comp!("[a,b]", "a*b == 8")([1,2,3], [4,5,6]);
solution is a range, in this case a one element range, containing only
[2,4].
Philippe
>
>
>
> Maybe in this case an
>> 'alias possibilities[0] this' could do the trick:
>>
>> assert(x == 2);
>> assert(y == 4);
>>
>> Can we do alias someArray[0] this; ?
>>
>
> Well, we can do this:
>
> struct foo( R ) {
> R range;
>
> ref ElementType!R getFront( ) {
> return range.front;
> }
>
> alias getFront this;
> }
>
> --
> Simen
>
