Re: one thing we forgot

On Sat, 05 Jul 2008 14:19:40 -0400
Sandro Hawke <sandro@w3.org> wrote:

> 
> > You cannot determine a dialect just by its syntax. Examples are: LP
> > with stable model semantics and with well-founded semantics. 
> 
> In that case, as we've been over before, we just use different NAF
> operators (smnaf and wfnaf were Axel's examples).

If we use this as a guiding principle then yes, it solves the problem.  But
this has serious cost attached. I am just concerned with the notation
explosion effect and other undesirables.

For instance, suppose I am writing a stratified program that uses naf.
This would be within both stable model and W-F semantics. Which NAF symbol am
I supposed to use? If I want my ruleset to be acceptable by both, one would
need to invent a new dialect, which is in the intersection of the two dialects.
Or it will require those two dialects to carry one additional kind of negation,
stratified-naf, which can only be used in a stratified way, but otherwise would
be upward-compatible with both stable-model and w-f semantics.
Neither seems to be a good alternative.

> 
> > Closer to home: BLD and a (syntactically) BLD-like document with F-logic
> > semantics. The former does not have inheritance, while the latter does.
> 
> I'm not familiar with this difference.   Can you give me a test case?
> Two small RIF documents which would have different entailments or
> consistency?

Scratch that: inheritable methods use a different notation (*-> vs. ->).

But there are other examples. For instance, rule ids are used in different ways
by different semantics (while syntactically there is no difference).
For instance, BLD with courteous semantics (even without negation) would have a
different meaning. 

This one can also be overcome by changing notation, but I feel that this will
backfire on us. It is not hard to come up with a scenario similar to the one I
gave earlier.

> My intuition from watching languages evolve over the years is that you
> can always add new features to a language without disturbing the
> existing syntax.  It's not always as nice for users as a re-design which
> changes existing syntax, but since users don't write RIF directly,
> that's less of a cost here.

When you are talking about the evolution of a single language then I agree.
But here we are talking about ogranizing many different languages into some
kind of a Mendeleev table.

> > Designing dialects that can be disambiguated syntactically is going to
> > be tough and we don't understand this enough. 
> 
> We don't understand any of this perfectly, but we have to keep moving
> forward.
> 
> > I think Harold's proposal for an optional attribute is a good compromise.
> 
> Perhaps.  
> 
> Thinking more since my e-mail to Harold, I guess there is one case where
> it might be useful -- if the receiver knows the named dialect, it can
> detect and abort on errors where the sender didn't conform to the
> dialect it claimed to conform to.   But that seems like a small benefit
> for the cost and confusion.   It's also a violation of Postel's Law
> (which should, perhaps, be violated some times).

> (Meanwhile, it's up the the chairs, but I don't see any new information
> here, and we already decided at F2F10 not to make any other changes, so
> this discussion (as something that goes into BLD now) seems out of
> order.

The example about SMS and WFS above is new information.
Actually, I do not remember that we made a resolution that no dialect attribute
will be allowed. Did we?

> A dialect tag could be proposed as an extension, of course.)

Agreed. For BLD we do not need this attribute, but it could be added to FLD as
optional. Then the designers of new dialect would be free to decide to include
them or not.

This would work if you will not insist that such a thing violates some higher
laws and cannot be accepted as a matter of principle.


	--michael

Received on Saturday, 5 July 2008 18:53:36 UTC