Re: PRD review, part 1

Christian de Sainte Marie wrote:
> > 1.2.
> > 
> > RIF-PRD doesn't strictly extend RIF-BLD condition language (e.g. no 
> > logical functions)
> Indeed. My understanding was taht BLD had been separated from Core to 
> free it from the constraint to be extensible to PRD. No decision about 
> what will or will not be in BLD made any reference to extensibility to 
> PRD. So, I did not consider that extending BLD in a strict sense was a 
> constraint we wanted to enforce.

BLD was not separated from Core. It was separated from FLD.

> However, I am not sure that Core will not have the signature thing: my 
> understanding was that the signatures were not sued in BLD either, and 
> that they were there only because future extensions would need them. 
> Will that be any different for Core? Michael?

Yes. BLD does not have signatures. At least, not explicitly.

> >
> > 
> > slotKey might be a case where a Uniterm TERM makes sense, if it can 
> > represent a frame "method".
> > 
> > I don't think the syntax diagram in 2.1 allows nested frames (disagrees 
> > with the presentation syntax here)

I think Gary meant things like

  obj[meth(args) -> val]

not nested frames.

Gary: yes, the purpose of uniterms in the "slotkey" place is to represent
method invocations.

> > I suspect that aggregation is at least as important in logic dialects as 
> > in production rules.  That is because logic based languages are 
> > frequently used for querying, and querying frequently uses aggregation. 
> > Consider SQL and, to a lesser extent,  prolog.
> > 
> > I would rather wait a bit and work to make sure we don't diverge too 
> > much here.  I find the linking of aggregation and quantification 
> > confusing.  I guess a SUM doesn't exist if there isn't anything to sum, 
> > but the COUNT exists and is zero if there isn't anything to count.  But 
> > maybe your intent was simply to reuse the <declare>.  May Aggregation 
> > should be a QUANTIFICATION?  (I suspect my questions are adequately 
> > reflecting my confusion :-)
> Aggregation is what took me the longest to figure out (and is one big 
> part of why it took me 3 months to produce the second draft after 
> Boston)... So, it is way to late today to comment on that: you will have 
> to wait until Monday for some explanation of why I propose to do it that 
> way :-)

Hmm. I thought you were fixing the other numerous problems in that draft :-(

I would start with trying to define a real semantics.


Received on Saturday, 16 February 2008 07:57:19 UTC