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.

Yeah, there are costs to any approach, for sure.

> 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.

I don't remember the full discussion we had, looking at Axel's NAF
proposal, but I think it's probably okay to have stratnaf be the first
cut, and when people need something more they have to pick wfnaf or
smnaf.

(I'm phrasing that in the programming language sense, I know.)

> > > 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 wa ys 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.

There may be nightmare scenarios...    I'm expecting we'll find clever
ways, if necessary, to make them not too, too bad.

> > 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.

*shrug*   I'm not sure I see the difference.

> > > 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).

I certainly would rather have a clear technical discussion/consensus
than argue about process, but ... what the heck...  :-)

> > (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.

I'm not sure how it's different from what we've talked about before, eg
http://www.w3.org/2007/07/10-rif-minutes.html

    axel describes his extension on NAF

    axel: extension of core with naf

    ... three extensions stratified negation, well-founded semantics
    semantics and stable model semantics for negation 

> Actually, I do not remember that we made a resolution that no dialect
> attribute will be allowed. Did we?

I doubt such a resolution was made, per se, but I know the "Last Call"
resolution was:

    RESOLVED: Advance BLD to Last Call, pending satisfactory completion
    of the edits decided at this meeting. 

... and adding this attribute was not such an edit.

> > 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.

Vendors can't add this local extension unless FLD licenses it?  That
can't be right.

> 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.

Heh.  I think the most we can to is give dialect/extension designers
good reasons for designing certain kinds of dialects/extensions and hope
they are persuaded.

      -- Sandro

Received on Sunday, 6 July 2008 00:55:44 UTC