Re: a "modest proposal" for PRD

some answers ...

Christian de Sainte Marie wrote:
> Hi Gary,
> We will discuss your proposal at the F2F; here are just a couple 
> questions and first thoughts, off the top of my head.
> Gary Hallmark wrote:
>> Start with exactly the BLD syntax.
> Is that feasible? E.g. what about logic functions?
One can't tell from the syntax  alone whether f(?x) is a logic function 
or an evaluated function.  It depends on the semantics.
Furthermore, I think that given syntax such as f(?x) = 
builtin(unary_minus(?x)), one should be able to give a suitable 
semantics for user defined (evaluated) functions.
I think we need to find the right balance between the possibility that 
people will be confused that f(x) is not a logical function in PRD and 
the probability that people will be confused about why all their 
functions (in PR) have to be wrapped in builtin().
>> Add just 1 or 2 "hard" things (e.g. retraction and rule priority) 
>> that are common in PR and make a model theory very difficult.
> Do you mean that PRD should include a model theory of PR systems? 
No.  I said "very hard" because I do not know for a fact that retraction 
and rule priority are impossible to express in a model theory.  I would 
not encourage the WG to tackle something "very hard".  I am simply 
motivating the use of operational semantics (and asserting that that is 
not "very hard").
> I do not know if this is feasible, but, assuming it is, what would be 
> the benefit wrt an operational semantics (depends probably on the 
> audience we target and the purpose we see for that document, I guess)?
>> Do not respecify the syntax, just add the new elements.
> Re respecifying the syntax : do we agree that the syntaxes of BLD and 
> the current PRD draft are the same (except on logic functions, 
> aggregation and actions, and pending some questions about naming and 
> one suggestion about stripping - ok, that makes already some 
> differences)?
My point really is that because of the different presentation styles of 
the current FLD/BLD vs. PRD, it is hard to tell how different they are.  
E.g., I just noticed that PRD's Forall has TWO Conditions, whereas BLD 
has ONE.  I should be able to put the BLD and PRD syntaxes side by side, 
and differences like Forall "jump out".
> If so, I understand that you want the syntax of PRD presented exactly 
> the same way as the syntax of BLD is: is that what you mean? Benefits, 
> drawbacks and sustainability of that approach need be discussed.
>> Develop an Operational Semantics for it, as defined by Plotkin in 
> Any salient reason for that specific choice? (I have some reservation, 
> but that is after reading only the first sentence :-)
It's a classic way to specify the semantics of languages in terms of 
states and state transition rules.  I'm not an expert in this field.  
Maybe something better has come along in the 25 years or so since this 
was written.
>> Do not spend time on informal semantics that can only diverge from 
>> the formal semantics. 
> The term "informal semantics" might have been a bad choice (it comes 
> from the Boston discussion), but a description of the intended use 
> when describing a construct seems rather useful for the reader, if we 
> want to separate the specification of the syntax from that of the 
> semantics.
> Why can that description of the intended use "only diverge from the 
> formal semantics"? Does it in the current PRD draft?
why does my Java code sometimes diverge from the comments?
> On the other hand, the specification of the normative semantics in the 
> current draft of PRD being structured exactly the same way as the 
> description of the syntax, it is only a matter of cut and paste to 
> replace the current "informal semantics" by the "normative semantics 
> for each construct.
> Now that you suggested it (indirectly :-), I can see the benefit of 
> doing that. A drawback could be the lack of a single place where the 
> complete semantics is specified... Hmmm, it is in three different 
> places in the current draft, anyway...
> Re "formal semantics": when you write "formal", you mean "using a 
> mathematical formalism"? If so, what is the benefit wrt the kind of 
> specification we have in the current draft (which need certainly lots 
> of improvement, but I am talking about the approach, not the current 
> state of the spec). Depends on the intended target audience/purpose of 
> the spec, again, I guess.
I'm hoping for something precise, concise, and unambiguous.
>> Only after PRD has caught up with BLD in terms of semantic rigor 
>> should it incorporate negation, aggregation, other actions, etc.
> That seems to imply that the approach taken in the current draft is 
> not, or not easily, amenable to the same level of semantic rigor than 
> BLD: is that what you mean?
I'm not sure I can clearly state what the current approach is.  Can you 
cite a reference or point to another spec that uses this approach?
> It also implies that the current draft is in a rather bad state, in 
> terms of semantic rigor. Michael wrote that as well. I wonder why: I 
> mean, of course, there are probably ambiguities remaining in many 
> places, but I thought that it was rather rigorous.
> Can you point to specific places where the specification of the 
> semantics lacks rigor?
For example, the terms "operational semantics" and "data source" are 
never defined.  If I lookup "operational semantics" on wikipedia. I get 
a reference to Plotkin's work, but I don't see anything that lets me 
readily identify what is in PRD as an operational semantics.
>> The task of developing a formal Operational Semantics for PRD is not 
>> trivial and would be best attempted by someone who has done something 
>> similar before.
> Again, I assume that "formal" means, here, "using a mathematical 
> formalism". And same interrogation again about the intended benefits...
> Not to mention that the first PRD strawman proposed such a "formal" 
> approach, based (heavily based, to the point of copy-paste in many 
> places) on wrtings by people who had done this before (Michael Kifer, 
> Claude Kirchner and Hassan A´t-Kaši, to name them) and that approach 
> was rejected in Boston as off target and unlikely to converge to 
> something useful in a finite time...
No.  A model-theoretic semantics was rejected for PRD.
> One underlying question I have in mind, of course, is whether the 
> current draft is really hopeless to the point that throwing it away is 
> the most efficient path to a useful PRD-RIF?
> I would not think so, but, of course, I am biased :-)
Christian, I suspect that I would do no better trying to formalize a 
semantics for PRD.  It's just not my area of expertise.  But I also 
suspect that if you are unfamiliar with Plotkin's work, it may not be 
your area of expertise, either.  I think we need to appeal to the 
WG/community for help here...
> See you all tomorrow.
> Cheers,
> Christian


Oracle <>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204

Received on Wednesday, 20 February 2008 20:19:46 UTC