Re: notes from Presentation Syntax task force meeting

On Sun, 22 Feb 2009 02:36:06 -0500
Sandro Hawke <sandro@w3.org> wrote:

> > Good progress. Sorry I could not attend the telecon.
> > But I do have a number of comments, below.
> > michael
> > 
> > On Fri, 20 Feb 2009 13:21:42 -0500
> > Sandro Hawke <sandro@w3.org> wrote:
> > 
> > > 
> > > IRC log: http://www.w3.org/2009/02/20-rif-irc
> > > Present: Harold, Chris, Sandro
> > > Agenda:  http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0113
> > > 
> > > (Here's what I think we agreed.  Chris and Harold, correct as desired.)
> > > 
> > > Conclusions on presentation syntax issues:
> > > 
> > >    -- We agreed that "pd" in the metadata of example 4 of BLD was an
> > >       error and should be "_pd" or "pd"^^<rif:local>
> > > 
> > >       At some point we might allow a declaration ("local(pd)") which
> > >       would allow one to use "pd" like that.
> > > 
> > >    -- We agreed to add separators to the syntax, making it more like
> > >       other languages with infix operators, so that:
> > >           Group(p(a b (c+d) e(c+d) f (c+d)) q(a))
> > >       would instead be written something like:
> > >           Group(p(a, b, c+d, e(c+d), f, c+d); q(a))
> > > 
> > >       This will alas require transforming all existing test cases and
> > >       examples; Sandro will investigate automating that transforming,
> > >       or simply saying those are written in a different PS.
> > > 
> > >       (I'm not really happy about this, but have no better idea.)
> > > 
> > >    -- We agreed that CURIES and bare IRIs which do not contain
> > >       delimiters (but do contain operators) could be allowed.  As a
> > >       consequence, infix operators like "-" and "+" will have to be
> > >       surrounded by whitespace.
> > >            f(my:max-width - 12)  has a subtraction
> > >            f(my:max-width-12)    has no subtraction
> > >            f(4-12)           is disallowed, to keep people using spaces
> > > 
> > >       (I'm not really happy about this, but have no better idea.)
> > >            
> > >    -- String literals can have escapes (like \") as in turtle
> > >       http://www.w3.org/TeamSubmission/turtle/#sec-strings
> > >       (except the \>, which isn't needed since in RIF you can always
> > >       use rif:iri instead of <foo:bar>)
> > > 
> > >    -- We'll allow C++ syntax comments as a shortcut
> > >       for (* _some_new_term[rdfs:comment->"...stuff..." *)
> > >       if Sandro can come up with a decent way to parse & attach them
> > >       (Actually we said comments starting with "#", but in typing this
> > >       I realized that conflicts with InstanceOf)
> > > 
> > >       Actually does it need to be 
> > >         (* _some_new_term _some_new_term[rdfs:comment->"...stuff..." *)
> > >       ?  I can't tell from the spec.
> > 
> > I don't really understand how you are planning to do that without requiring
> > some kind of structure in those C++ comments.
> 
> Let me back up a little.
> 
>    - I said, I really need a simple comment syntax.  It's crazy
>      to be writing in some language and not be able to to make
>      comments (without the incredibly painful syntax seen above).
>      I just wanted some syntax that the parser would strip.
> 
>    - Chris said that we agreed comments should be carried through as
>      metadata.
> 
>    - I said, well, yeah, I guess I my parser could gather up the comment
>      strings and -- instead of throwing them away -- insert them as
>      rdfs:comment metadata.  The hardest part is probably knowing what
>      node in the AST to attache the comment to -- but maybe it doesn't
>      matter too much.
> 
> Does that make more sense? 

Yes. You can probably use the same rule to decide which syntactic element to
attach it to as the one used for the metadata. The Id of the frme could be
a Skolem constant.

> Something else you COULD do:
> 
>     //Author: Sandro Hawke
> 
> as a shortcut for some dc:creator metadata -- but that's NOT what I'm
> looking for here an now.  I want to be able to comment out code, to have
> half-written code, to have little notes to myself, etc.

The above would require the user to learn yet another language. At least,
another vocabulary (eg: Author = dc:creator, etc.)

> > >    -- Regarding literals like 123.456, we'll require a suffix to tell us
> > >       which datatype to use:
> > >           123.456d ==> "123.456"^^<xs:decimal>  
> > >           123.456e ==> "123.456"^^<xs:double>   (as in Java/C)
> > >           123.456f ==> "123.456"^^<xs:float>    (as in Java/C)
> > >       (123.456e+02 and 123.456f+02 are double and float, as usual)
> > > 
> > >    -- We'll allow formulas as terms in the general grammar
> > >       eg:   p(1, 2, (p(1) :- q(2)), 3)
> > >       since some dialects might use them
> > 
> > This is allowed in FLD, yes. The formula is treated as being reified.
> 
> But what if we require braces, as below...?

Yes, this is possible. (See also below.)

 
> > >    -- Responding to Chris's strong dislike of "->" as very confusing in
> > >       a logic language, we finally settled on "::" to replace it in NAU
> > >       and frames.
> > >       eg:    p(b :: 1, bb :: f[my:color :: your:red])
> > 
> > I can't imagine anything uglier than this particular choice.
> 
> Yeah, Harold said you probably wouldn't like it.  
> 
> Do you have any suggestions for what we could use other than "->", which
> Chris objects to on the grounds that it looks an awful lot like like the
> "implies" arrow?

Not really. The only two symbols that are widely familiar to people are the ->
and the :. The colon will be confusing, as you mentioned, because of the curies.

> For my part, I don't mind the arrow too much.  I've spend some months
> here and there using Otter -- for which it is the implication operator
> -- but I spent much more time using C and C++ for which it is the
> "member by pointer" operator.  That usage is kind of like this F-Logic
> usage, and yet quite different....

Right. And since the arrow is inside the term and not at the top level, it
cannot be confused with the implication. 

 
> Some other options we talking about:
> 
>        -- nothing (whitespace), which we might be able to parse, but
>           could still get confusing
> 
>              object[property value]
> 
>        -- single colon, which is perhaps my favorite, but runs more risk
>           of being confused with namespace stuff (even if we require
>           whitespace):  
> 
>              object[property : value]
> 
>           [For myself, I think the namespace separator ought to be
>           underscore instead of colon, or cleverly dot (as in python),
>           but I guess I'm too late on that one.]

As you said, the above are not really good options.

>        -- colon-equals, suggesting the value is assigned to this property
>           
>              object[property := value]

This is less objectionable but assignment is a wrong connotation,
especially in the body of a rule. Also, a[b:c := e] isn't pretty.

>        -- equals, which we could parse (I think) if we require formulas
>           inside terms to be wrapped in bracess
> 
>              object[property = value]

This is like := but looks better with curies.


> Anything else?  There are things I like and dislike about all these
> options.
> 
> > > Conclusions on other issues:
> > > 
> > >    -- It would be nice to anonymous frames.  In PS, the syntax could be
> > >       _[attr->value]    (or  _[attr :: value])
> > 
> > There is more to anonymous frames than that. What is needed is a general synt
> > ax
> > for skolem functions/constants. The anonymous frame is just a special case of
> > that. In FLORA-2, there are two kinds of symbols for Skolem symbols: _# and
> > _#<number> (ie, _#1, _#2, etc.). This allows skolems to be cross-referenced
> > within the same formula (eg., when you skolemize an existential var, which
> > occurs in several places in the same formula).
> 
> Why not just use existential vars, and let systems Skolemize if they
> need to?  (And then an anonymous frame is just a frame whose object is
> an existential variable, implicitely scoped at the innermost containing
> formula.)

Because existentials and skolem constants are not the equivalent. This is why
in rules existentials in the heads are not allowed, but constants are allowed.


> > >    -- It would be nice to have nested frames, and more generally frames
> > >       in terms.  Can we please add them back?  They're just syntactic
> > >       sugar (unless you have anonymous frames).
> > 
> > In FLD, a nested formula is not syntactic sugar. It is a reified formula.
> > To distinguish syntactic sugar from reification, some syntax is needed.
> > For instance, a[b->{c[d->e]}].
> 
> Oh!  I thought (perhaps wishfully?) that in F-Logic you could write:
> 
>      sandros_car[color->green, maker->honda[located_in->Japan]]
> 
> and if it occured as a formula, it was syntactic sugar for:
> 
>     sandros_car[color->green, maker->honda] and honda[located_in->Japan]
> 
> I also thought you could do the same sort of thing in a term, so
> 
>       p(x) and q(sandros_car[color->green])
> 
> was syntactic sugar for:
> 
>       p(x) and q(sandros_car) and sandros_car[color->green]
> 
> Have I been wrong about these?

You are right about this: in F-logic and in FLORA-2 nested frames are syntactic
sugar. But the presentation syntax was designed to be abstract (by popular
demand), so the emphasis was on expressivity and not on syntactic sugar.

There is one more issue here. What about things like p(a[b->c])?
Should it be a syntactic sugar for "p(a) and a[b->c]" or p of a reification of
the formula a[b->c]?
To have a consistent grammar, the decision here should be the same as in the
case of frames. So, in FLORA-2 it is the former (syntactic sugar). To reify, one
needs to enclose the formula inside ${...} as in p(${a[b->c]}) (btw, simple
{...} won't do because {...} is used as a shortcut for the set symbol (and also
for constraints in LP).
Interestingly, the experience shows that in case of the frames, people prefer
that the default for
a[b->c[d->e]]
be the shortcut, ie, "a[b->c] and c[d->e]".
But in case of other nested occurrences, they prefer the other way around, ie,
that
p(c[d->e])
would mean that c[d->e] is a term that represents reification of the formula
c[d->e].

I don't have an ideal solution for this.

michael

Received on Monday, 23 February 2009 21:24:32 UTC