Re: notes from Presentation Syntax task force meeting

The problem is that : is used for curies. If we use it, then we have to require
spaces around, and it becomes unreadable:

foo:bar[moo:bar : shoo:bar].

Actually, a (long) while ago I proposed to use mnemonic names as in WSMO
(long, but clear):

-> --- hasValue
#  --- memberOf
## --- subclassOf

but somebody shot it down.

I am not married to ->, but just don't see a good alternative (that others
would also approve). In fact, I myself *hate* # and ##, but avoided raising this
issue in the interests of global peace. If : is game, then I would rather use
it for membership and :: for subclass, as in a number of o-o languages.

michael


On Sun, 01 Mar 2009 20:42:12 -0500
Chris Welty <cawelty@gmail.com> wrote:

> 
> Michael,
> 
> Why don't you just pick something for slots - *anything* other than "->" is fine 
> with me.  I'm OK with ":", I don't find that nearly as confusing since it is 
> used in so many contexts everywhere my eyes don't expect it to mean anything 
> without parsing context.  "->" is not like that for me (as a C++ programmer, I 
> used "(*ptr)." instead).
> 
> -Chris
> 
> Michael Kifer wrote:
> >>>>    -- 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, 2 March 2009 02:08:04 UTC