Re: notes from Presentation Syntax task force meeting

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 01:43:16 UTC