Re: handling state the database way

Hi Richard, thanks for your comments.

I have indeed written a library, and  think it
does provide benefits over the unstructured asserting/retracting
that is usually used to implement this sort of thing - the initialiser
can check that the single fact (actually, the single recorded item,
as I thought I'd try using the recorded database) is not hanging around
from last time, possibly indicating a bug in the program; also get/set/update
can throw an exception if the fact isn't there, and finalise can do the same.
And of course, the program text now makes it very clear when
mutable state is being used.

HOWEVER - having done that, I've just looked up nb_getval/2, nb_setval etc
for the first time and realised they already do pretty much what I was
talking about.  So that's that.

I get a sense that people are holding their noses as I talk about
mutable state. Well I am too - I avoid using it wherever possible, which
is very nearly always. However, one of the situations where it is
hard to avoid is when an algorithm needs to carry state over 
backtracking, which can happen when providing certain meta-programming
facilities, such has first-N solutions.
In my case, I am studying David Poole's code for probabilistic Horn 
abduction. I don't fully understand the implementation yet, but it looks
like that, essentially, it is capturing and manipulating continuations. 
This suggests what might be a more elegant alternative: to be able to 
reify the state of the Prolog engine (i.e. an ongoing refutation that 
may have produced a result but still have more results available by 
backtracking) into a term.  As people working in functional languages 
have shown (see e.g.  Filinski,  Kiselyov, Shan  http://okmij.org/ftp/continuations/),  
capturing a (delimited)  continuation is a very powerful capability indeed.

Searching for 'prolog continuation' as I write, I see that Jan has done some 
work with Tom Schrijvers on delimited continuations in Prolog, as as Ulrich
Neumerkel. Is there any chance of this making it into SWI?

cheers,
Samer


On 16 Feb 2014, at 22:26, "Richard A. O'Keefe" <[email protected]>
 wrote:

> 
> On 15/02/2014, at 7:28 AM, Abdallah, Samer wrote:
> [To paraphrase:] Why can't I *see* the structure?
> 
> May I suggest a module?
> 
> First draft:
> 
> :- module(single_fact, [
>    initialise/2,
>    update/2,
>    finalise/1
>   ]).
> :- meta_predicate
>    update(+, 2).
> 
> :- dynamic store/2.
> 
> initialise(Key, Datum) :-
>    retractall(store(Key,_)),
>    assert(store(Key, Datum)).
> 
> update(Key, Updater) :-
>    retract(store(Key, Old)),
>    !, /* green cut */
>    (   call(Updater, Old, New) -> F = true
>    ;   New = Old, F = fail
>    ),
>    assert(store(Key, New)),
>    F == true.
> 
> finalise(Key) :-
>    retractall(store(Key,_)).
> 
>> 
>> 	:- dynamic some_pred/1.
>> 	update(Event) :-
>> 		retract(some_pred(OldState)),
>> 		update_something(Event,OldState,NewState),
>> 		assert(some_pred(NewState)).
>> 
>> 	initialise :
>> 		retractall(some_pred(_)),
>> 		assert(some_pred( <Initial state> )).
> 
> This becomes:
> 
> 	initialise :-
> 	    single_fact:initialise(<<key>>, <<initial state>>).
> 
> 	update(Event) :-
> 	    single_fact:update(<<key>>, update_something(Event)).
> 
>> 
>> Obviously, one could write a library to do this, but I think there might be
>> benefit in performance, atomicity and control over backtracking behaviour
>> that might come from it being integrated at a lower level, like flag/3.
> 
> Yes, but the library stage comes *first*.
> 
> By the way, there's a proposal for adding mutable variables to
> ISO Prolog, relevant to this.  I am afraid that after printing
> a copy of the proposal and skimming it, I hurled it into the
> nearest paper recycling bin in horror and disgust at the very
> idea.  But if Prolog _is_ to end up with green worms wriggling
> behind its eyes (see Stross's Laundry series for the key to
> this metaphor) it would be well if they were the *same* green
> worms.
> 
>> 
>> What do you think? Is it the case that the cost of doing unification on the
>> state means that it is not worth the small gain of making it a built-in?
> 
> The cost of unification is unlikely to be high.
> What counts more is how expensive everything *else* the applications
> are doing.  And really, the only way to find out is to start with a
> simple library module and do some profiling.
> 
> I will say that any Prolog program that spends a lot of its time
> in the single_fact: module will be in desperate need of
> restructuring.  Or possibly of rewriting in Visual Basic.NET.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.iai.uni-bonn.de/pipermail/swi-prolog/attachments/20140217/e10e9ba9/attachment.bin>