Re: notes from Presentation Syntax task force meeting

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

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

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

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

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

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

       -- equals, which we could parse (I think) if we require formulas
          inside terms to be wrapped in bracess

             object[property = value]

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

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

      - Sandro

Received on Sunday, 22 February 2009 07:36:27 UTC