Re: How core is Core?

Sandro Hawke wrote:
>>    "why do we continue to talk about all dialects extending Core and 
>> everyone implementing Core when that seems unlikely given that Core has 
>> term unification? what does that imply for the extensibility mechanism, 
>> do we need profiles or something?"
> 
> I think of the decision about what goes into Core or other dialects as
> essentially a marketing question.  Does that seem right?

Depends what you mean by "marketing" :-)

It is about defining interoperability points. Defining a set of rule 
features, expressible via RIF, that some set of systems can use for 
interchange.

As Paul says, this largely only makes sense for sets of systems that are 
fundamentally compatible (e.g. a set of PR languages or a set of LP 
languages but not necessarily a mixed set).

We need interoperability points because if each system implements a 
different subset of the supposedly shared dialect you don't get reliable 
interchange.

> RIF software doesn't have to know what's in Core or any other dialect,
> except when constructing good error messages.  Implementors decide which
> components they will implement, and that's what the software knows
> about.

Suppose I'm working in some language L and I want to export my ruleset 
so that my partners can all use my rules. They all work in other 
languages which are members of the same broad language family.

Don't I want to identify some target RIF dialect D and tell my export 
software to make sure my rules fit within D so that I can be sure all of 
my partners' systems will be able to reliably run my rules?

So doesn't the export software need to know the precise constraints of 
dialect D? That may be different from the set of components that the 
system implements (which may be a superset of dialects D, E and F).

Don't I want the resulting export document to be tagged with metadata 
saying it is intended to fall in dialect D so that my partners know to 
try importing it into a D-compatible engine?

> I'd like to see us defining and characterizing components, mostly
> separate from whether they will be in Core or not.  Maybe we'll focus
> more on the ones for Core, but I think we'll really just each focus on
> the ones we each want, whether they end up in Core or not.

It's not clear to me how much the features we are talking about divide 
neatly into "components".

Specifically the feature I picked on here was term unification. AFAICT 
that is not a separable component in Core as currently defined.

What about the builtins library? Will each builtin be a separate 
component?  Builtins also interact with the function symbols decision of 
course.

There is also the question of whether components are all or nothing. It 
seems to me there are cases where a dialect may impose a syntactic 
restriction rather than define a new component.

For example, equality is currently symmetric. Perhaps in some dialects 
we might treat equality as more like assignment and restrict the LHS to 
be a variable not a general term.

Another example consider a DL-like dialect that would want to limit 
predicates to unary and binary. [I know the RDF embedding will be using 
frames instead of predicates so that such a dialect is not currently on 
the table but it is not an unreasonable dialect restriction.]

> It may be that we'll do the core-or-not-core labeling much later in the
> process.  We can, I think, go to Last Call and Candidate Recommendation
> with components published as "as risk" for Core, saying we'll figure out
> later, based on implementation experience, whether they belong in Core
> or not.  Basically, we'll include them in Core unless someone ends up
> really finding them too hard to implement.

That makes sense for the written spec if we really do want Core to be 
core, so long as the spec can be structured so that these "at risk" 
pieces are sufficiently well separated.

An alternative is to say that Core is not core it is just a starting 
point for dialect design and concrete dialects will pick and choose from 
Core as appropriate. That's what I understood to be MichaelK's position.

[Snipped lists discussion in this partial reply.]

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 2 July 2007 16:16:03 UTC