Re: Networking in Prolog - a survey

On May 22, 7:33 pm, Alessio Stalla <alessiosta...@xxxxxxxxx> wrote:
On 22 Mag, 12:49, "rupertlssm...@xxxxxxxxxxxxxx"



<rupertlssm...@xxxxxxxxxxxxxx> wrote:
On May 21, 6:49 pm, Alessio Stalla <alessiosta...@xxxxxxxxx> wrote:

avoid that concern for now. Of course that doesn't really solve the
problem in general since the code triggered by events will eventually
have to cooperate with code running on the main thread, but in my
limited scenario, in which event handling will simply be some limited
processing of the received data and possibly an assert to augment the
current theory, that problem isn't influent.

Alessio

I think that that assert could be problematic. What if one interpreter
loop unifies against the current theory, then another asserts a new
fact, then the original unifies against the new theory and gets a
different result? That is what you want, but how to make sure that it
can only happen in predictable ways? Will be interesting to see what
solutions you come up with.

I don't think that is a problem, no more than an assert in single-
threaded code is. If the interpreter starts solving a goal, and in the
meantime the theory is modified, either it will see the newly asserted
clause or it won't. The goal might produce different results, but
that's precisely what I want. I can't imagine how that could break the
interpreter, but maybe I'm missing something.

Regards,

Alessio

Ok, I see what you mean. Assert in single-threaded code can be
confusing. I think what I meant to say is that assert/retract could be
problematic, with the retract being the problematic one. What if you
are part way through unifying against a clause and it dissapears in
parallel? In single threaded code that would not happen, but with
threading it can. Sounds like this can be solved with a bit of
synchronization in the Java code to make sure that parallel
interpreters don't blow each other up. It does not need to be exposed
as a feature at the Prolog level. Users can assume that clauses will
appear and dissapear in non-deterministic ways, but that they will
always do so atomically.

Another possibility to consider might be if you do multiple asserts/
retracts in parallel. At the end of a sequence the theory is left in a
'correct' state. But part way through it is potentially in an
incorrect state that will cause you program to crash. To protect
against that you need a transaction round the whole sequence. Maybe
this is something you can live with though, perhaps your network
handlers might just assert a single fact (containing the data) and
nothing more. Then there might be a main interpreter loop that polls
the network data facts, possibly retracting them once they have been
consumed.

Have you taken a look a transaction logic to see if that offers any
insights?

Rupert
.

Relevant Pages

  • Re: Networking in Prolog - a survey
    ... If the interpreter starts solving a goal, ... clause or it won't. ... Assert in single-threaded code can be ... Have you taken a look a transaction logic to see if that offers any ...
    (comp.lang.prolog)
  • Re: Networking in Prolog - a survey
    ... limited scenario, in which event handling will simply be some limited ... I think that that assert could be problematic. ... loop unifies against the current theory, ... If the interpreter starts solving a goal, ...
    (comp.lang.prolog)
  • Re: Static typing in py [was Re: Some notes]
    ... > Josiah> my hopes up. ... > Implementation can be trivial - the interpreter could just assert ... > coming up with all the semantics. ...
    (comp.lang.python)
  • use variable internal number
    ... if I assert a new clause, ... e subsequently retract that clause: ... ps. I'm using SWI-prolog. ...
    (comp.lang.prolog)
  • Convert a "global variable"
    ... I use assert / retract to set a value which should be accessible in the same ... way as a global variable in a functional language. ... I could pass the "global" variable as argument between all predicates of my ...
    (comp.lang.prolog)