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

we aren't all quite on the same page.  Neither Christian nor I have 
proposed that the semantics of assign would be any different from the 
semantics of retract+assert.  And no one has yet proposed workable 
syntax that is different, either.

I think the confusion here is in assuming that the existing assert and 
retract, as currently specified in PRD, work as in most PR languages.  
They do not.  Existing assert and retract are per slot when applied to 
frames.  You'd have to write a rule like this to retract everything 
about a "fact" ?o

Forall ?s ?v (Retract(?o[?s->?v]) :- ...)

Maybe we even need (Retract(?o#Type)

Mark Proctor wrote:
>
> 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 2.2.1.3 (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
>>
>>
>
>

Received on Tuesday, 1 July 2008 15:00:26 UTC