Re: PRD review,Part III, sections 3,4,5

Christian de Sainte Marie wrote:
>> Part III will follow.
> And replies, comments, requests for clarification regarding it too :-)

Here we are...

> 3.1. Do we really need new constructs such as Execute and Assign, when we
> already introduced procedural attachments (whatever named) and equal
> assignment in the condition part?

Even if you consider them procedural attachments, Execute and Assign are 
not the same kind of procedural attachment as builtins and user-defined 
fixed interpretation functions: they are meta-level constructs.

This being said, are you suggesting that whatever has to be executed 
need not be wrapped into an Execute construct? Why not; although this 
would probably conflict with the suggestion to remove the Assert wrapper 
around asserted ATOMICs to make the syntax identical between PRD and 
Core/BLD. To be discussed. I added a note.

Re reusing the Equal construct for assignment, see my previous replies.

> 3.2. Yes, we need some sort of state transition semantics. But I can not see
> where it is defined in this section?

Obviously, the need for an overview, again :-) It is specified in the 
Rule section...

> In my opinion we should define a state
> transition semantics considering the effects of actions leading to snapshots
> of the world and we should consider in this semantics the inherent
> non-deterministic nature of production systems, i.e. computations on the
> possible courses of actions leading to a computation of the output state.
> This semantics should be defined without negation-as-failure and should be
> aligned with the semantics of BLD. 

What do you think, after reading section 4.2.2?

Why without negation?

> Regarding, NAF:  we might consider it (later, since it is urgently needed),
> but we there a many ways to describe the semantics (operational or more
> declarative) of NAF for production rule systems and how to handle
> non-determinism, loops, and transactions with roll-backs in these semantics.

To be discussed along with what is called "ending conditions", "agenda 
sorting algo" and "rule firing algo" in section 4.2.2., indeed.

Off the top of my head, I would say that transactions with roll-backs 
are beyond the scope of PRD and belong to an extension, but this is to 
be discussed.

> 4. I agree and would prefer a general Rule construct, but maybe a rule in
> BLD should be also called Rule.

I am confused: isn't it the case? Or, are you talking of the name of the 
if-then construct (Implies or else)?

> To distinguish production rules from
> derivation rules we should not use if - then but "if Condition(s) do
> Action(s)".

On the other hand, we want to keep PRD as close as possible to Core and 
BLD, syntactically as well as semantically (see Gary's comments).

> Rulesets are needed, but need to be discussed together with the
> concept of a module.

Ok. There is an issue on modules for BLD, too, but it has been 
considered not to be critical path for Final Call (issue 46).

> 4.2. Similar arguments as for the previously given descriptions of the
> operational semantics of PRD. The described operational semantics as general
> semantics for all production rule systems lacks an intuitive motivation and
> makes a full understanding of their technical results and consequences
> difficult.

Ok. I think that is because it (the specification of the semantics of 
PRD) was intended to work the other way round: it is the specification 
of an interchange format, not a PR language.

I mean, the idea is that the reader has a specific production rule 
system in mind, for which he intends to develop a RIF-PRD compliant 
translator: the spec is written in a way that is intended to make it 
easy for such a reader to find if and how the constructs in his PR 
system map onto RIF-PRD and reciprocally.

The point is that the reader is supposed to understand the technical 
results and consequences of the constructs in his PR system, and that he 
needs only to check whether and how they translate into the RIF-PRD 
constructs: if the main use case was for readers wanting to understand 
the technical results and consequences of RIF-PRD constructs ex 
abstracto, it would certainly need a completely different presentation, 

Do you think that adding something about that as a kind of "reading 
guideline" in the introduction would help?

Thanx again for your comments.

See you in Paris,


Received on Tuesday, 19 February 2008 14:14:59 UTC