Re: message queue put-back and backtracking

> On Friday 12 January 2007 20:19, Samer Abdallah wrote:
>> On 12 Jan 2007, at 16:27, Jan Wielemaker wrote:
>>> Another disadvantage is that it makes thread_get_message
>>> non-deterministic.  Somewhat more in line with the desing might be
>>> a thread_send_message that puts the new message at the head rather
>>> than at the tail.  That allows for a design like:
>>>
>>> ndet_get_message(Queue, Message) :-
>>>        thread_get_message(Queue, Message),
>>> (   true
>>> ;   thread_send_message(Queue, Message, [at(head)]),
>>>    fail
>>> ).
>>>
>>> Note however that this implementation is not correct with respect
>>> to the
>>> cut.
>
> Simply consider
>
> (   ndet_get_message(Queue, Message)
> ->  fail
> ;   true
> ).
>
> With a truly logical predicate this would not change Queue.  After
> pruning the choicepoint however the message will not be put back.
>
> You can do the above with the current system easily (not tested):
>
> :- dynamic
> pushed_message/2.
>
> ndet_getmsg(Queue, Message) :-
> ndet_getmsg1(Queue, Message),
> (   true
> ;   push_back(Queue, Message)
> ).
>
> ndet_getmsg1(Queue, Message) :-
> retract(pushed_message(Queue, Message)).
> ndet_getmsg1(Queue, Message) :-
> thread_get_message(Queue, Message).
>
> push_back(Queue, Message) :-
> asserta(pushed_message(Queue, Message)).

>
>>> So, I'd prefer to consider the problem at a somewhat higher level
>>> first
>>> to see whether there is an elegant solution you missed there.
>>
>> Well, I would like to be able to solve the problem without invoking
>> another thread - essentially what I want is a findall that returns
>> a *lazy* list that carries enough information about the state of
>> solution search to build itself on demand as it goes along. I can't
>> see how to do it without using a meta-interpreter which handles
>> the search tree explicitly at the meta level.
>> My current transaction logic interpreter still relies on backtracking
>> in the underlying interpreter - doing otherwise would make it much
>> more complex. Hence the quick and i hope not-too-dirty multithreading
>> approach.
>
> I'm not very good at that, but you can hack some of these things using
> coroutining or attributed variables.  Its a really nice puzzle :-)

>
> Success --- Jan
>
>
> ------------
> For further info, please visit http://www.swi-prolog.org/
>
> To unsubscribe, send a plaintext mail with "unsubscribe prolog <e-
> mail>"
> in its body to majordomo@...