W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: [PRD] Issues to resolve before publication (Assign/Modify)

From: Mark Proctor <mproctor@redhat.com>
Date: Tue, 01 Jul 2008 13:10:24 +0100
Message-ID: <486A1EB0.9010500@redhat.com>
To: Christian de Sainte Marie <csma@ilog.fr>
CC: Gary Hallmark <gary.hallmark@oracle.com>, RIF WG <public-rif-wg@w3.org>

Christian de Sainte Marie wrote:
> Gary Hallmark wrote:
>>> #6. Section 2.2 (Actions): Assign or not Assign in FPWD? I propose 
>>> to keep it, now that it has been re-included with Ed: Adrian wants 
>>> it, Mark
>>> wants it, I am rather in favor, Gary balances. I added an editor's 
>>> note in section (Assign) to the effect that this was still 
>>> under discussion and that the syntax was liable to evolve.
>>> Gary, I see that you changed the examples: I did not check exactly 
>>> how, but if we agree on the above solution, you will have to revert 
>>> that change, right?
>> No, I will not revert the change because the syntax that was there 
>> did not work.  Because, as you say, the semantics of assign is 
>> exactly the semantics of retract+assert, and we have no better syntax 
>> than retract+assert, one wonders why we want an assign action.  If 
>> someone has a better syntax than retract+assert, then please propose it.
> Because all PR languages have it, in one form or another? Is that a 
> good-enough argument for having a modify operation in addition to 
> retract and assert?
modify is needed as it provide different execution than a assert+attract 
alone. While the internal implementat might be an assert+retract this is 
normally combined with other magic to give a more flawless execution. 
The changed fields are encapsulated within the modify command which also 
allows for better recursion handling (Jess Slot Specific, and standard 
Clips COOL behaviour) and can help with performance. The use of a modify 
command allows for event normalisation,  on a modify I don't want to see 
all activations cancelled and then re-created I only want to see the 
ones that actuall changed. Extra magic is needed for truth maintenance 
to stop logical chains being broken during hte modify, that an 
assert+retract on their own would cause. So something like the following 
is definitely needed:
(modify (?person) (name "mark") (age 32) )
> Btw, the reason why I think that the current Assigne(Frame) syntax 
> does not work has nothing to do with its semantics being the same as 
> retract+assert: it is rather that I see problems in confusing the 
> source and target in one same Frame expression.
> Also, Assign, like other forms of "modify", differs from 
> retract+assert, in particular when objects are deleted and created. 
> Since, in this WD, the semantics of assert and retarct does not deal 
> explicitely with that case, the semantics of assign seems to resolve 
> to retract+assert; but if its semantics being incomplete is a reason 
> to remove Assign, the same should apply to Assert and Retract too!
> I modified the editor's note about the semantics of actions to mention 
> specifically that it needed be refined wrt the creation and deletion 
> of objects. Does that help?
> Cheers,
> Christian

JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)
Received on Tuesday, 1 July 2008 12:13:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC