Re: notes from Presentation Syntax task force meeting

Michael Kifer wrote:
> 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

I *much* prefer these names to any punctuation!

-Chris

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

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Monday, 2 March 2009 02:24:07 UTC