notes from Presentation Syntax task force meeting

IRC log:
Present: Harold, Chris, Sandro

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

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

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

Conclusions on other issues:

   -- It would be nice to anonymous frames.  In PS, the syntax could be
      _[attr->value]    (or  _[attr :: value])

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

Received on Friday, 20 February 2009 18:21:50 UTC