Re: [PRD] PRD Review By Example

All,

Sorry I could not join yesterday. I could not even send a email, as I had no connection (I still have none, but I hope I will find one today :-).

I had prepared a couple comments to Gary's issues. I could not send them yesterday. I hope they are not too much off speed after you discussed Gary's email at the PRD telecon yesterday. Here they are, anyway...

(I found a place where I have a very slow GSM connection; let see if I can send this... Why is it everybody can use that wifi network and I cannot :-(

Cheers,

Christian
----------------------
Gary, all,

I will probably not be able to participate in the either the RIF or PRD telecon later today. So, here are my comments on the issues Gary raises (thanx for the useful discussion, Gary).

 Gary Hallmark wrote:
> 
> Issue 1: We must state that all "initial facts" in the ruleset RS (here, 
> p:A(0)) are removed from RS and become the initial working memory 
> w<sub>0</sub>

We did not specify constructs to represent initialisation yet. I do not know if we need them, but, indeed, this is a question to be raised and resolved. So, I suggest adding the sub-issue:

Issue 1': Does PRD need constructs for ruleset initialisation? That is, is that something that is commonly used enough in PR languages that we choudl have it in PRD?

Now, regarding that question of initial facts, all we can have in terms of initialisation, in a RIF-PRD document, at this stage, are ground assertions (actions) with empty (and thus always true) conditions, and these should be handled just like regular rules. 

If we want them to be fired first, it is for the conflict resolution strategy (PICK) to say so.

So, my understanding of Gary's proposed Issue 1 is that it is really equivalent to sub-issue 1'.

> Issue 2: INSTANTIATE returns a set of Inst(R). This is undefined.
> I guess it is a pair (rule-id, consistent-substitution), and that 
> furthermore it must return *all* such pairs.

Resolved. I had just not finished the job of moving things around cleanly.

> Issue 3: picked(c) from my new PICK specification should be changed to 
> mean the rule instance picked
> from the prior configuration to arrive at the current configuration. And 
> the transistion system that calls PICK must
> save the returned rule instance as picked(c').

Ok. I'd like to comment on that one too, but I feel I really should read your PICK email first :-)

> Issue 4: extractActions seems a bit underspecified as to how it 
> "grounds" the actions in the rules,
> which may have variables. Also, its argument should be a single rule 
> instance, not a list.
> I guess it is supposed to "plug in" the substitutions, so
> s = {p:A(1)}

Yes, the spec of extractActions is a bit light. The input is an orderet set of rule instances and not a single instance, because we have not decided yet if PICK returns always a single instance, or whether there are case where it returns a list. So, I suggest splitting the issue in two:

Issue 4: extractActions needs be specified more completely.

Issue 4': does PICK always return a single rule instance? That is, is it useful to have PRD prepared to handle conflict resolution strategies that select more than one rule instance to be fired?


> Issue 5: And(...) is undefined. We must define the PS before the 
> semantics if we use the PS in the semantics.

I do not understand: "And" is defined in the section about conditions. It is used there in about the same way as above; and so it is in BLD and FLD etc: what is it that makes its use in the spec of the transition relation an issue, specifically?

> Also, this And takes a set as its first argument. I'll replace the set 
> with its member:

Right, some sloppiness in the spec, indeed.

> ({p:A(0)}, p:A(1), w') →RIF-PRD if and only if, for every ground formula 
> φ in W,
> w' |= φ if and only if And(p:A(0) p:A(1)) |= φ
> 
> w' = {p:A(0) p:A(1)}
> 
> Note: w' is not uniquely determined. E.g. w' = {And(1=1 p:A(0) p:A(1))} 
> is ok, too. I guess this is fine.

I do not understand why it is not uniquely determined? Either 1=1 is something that is entailed by And(p:A(0) p:A(1)) or it is not. If it is entailed, it is in w', if it is not entailed, it is not in w'. Isn't that correct?

Of course, w is not only p:A(0) and p:A(1): it also contains all the ground tautologies that follow from the specification of the condition language, and all the ground facts that follow from the definition of the data types, builtins and, generally, all the external knowledge.

So, it is really And(w, f), T |= phi, where T represents any addtional theory that is used by the system (including, typically, the classification theory that is provided by an object model).

You did not want such additional theories to be mentionned in the spec of pattern matching, in the previous version of the document. But, maybe, it is now time to include it back, as we are closer to be able to represent references to these theories (as XML schema, per your action)?

> Issue 6: PICK is ill-defined.

Hmmm... I would not even say that it is defined :-)

There is barely a skeleton for a spec, in the current version. Needs flesh to be working, and input to decide what that flesh must be: very good that you sent that PICK email, indeed. It may also be interesting to have a look back in my initial proposal, that did not make it to the FPWD (and although it is flawed).

And the input from others in the group is highly welcome! I remind you that PICK will be the core subject of our discussions next week in Orlando...

Cheers,

Christian

Received on Wednesday, 22 October 2008 08:47:49 UTC