W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2008

RE: [BLD] comments on the semantics of lists

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Sat, 9 Feb 2008 13:45:27 -0500
Message-ID: <E4D07AB09F5F044299333C8D0FEB45E904FFDD80@nrccenexb1.nrc.ca>
To: "Jos de Bruijn" <debruijn@inf.unibz.it>, "Michael Kifer" <kifer@cs.sunysb.edu>
Cc: "RIF WG" <public-rif-wg@w3.org>

Hi Jos,

Syntactically, these would correspond to sorted Vars, e.g.
Var_LIST -- for LIST-sorted Vars -- in

LIST ::= 'Seq(' TERM* ')' | 'Seq(' TERM+ ` | ` LIST ')' | Var_LIST

Not having sorts, we suggested to allow general s-expressions:

LIST ::= 'Seq(' TERM* ')' | 'Seq(' TERM+ ` | ` TERM ')'


-----Original Message-----
From: Jos de Bruijn [mailto:jos1997@gmail.com] On Behalf Of Jos de
Sent: Saturday, February 09, 2008 1:38 PM
To: Michael Kifer
Cc: Boley, Harold; RIF WG
Subject: Re: [BLD] comments on the semantics of lists


The proposal looks good.  I like the more direct interpretation.

Regarding your note at the bottom of the page (about interpreting 
malformed lists):
I think we can easily change the syntax of lists to disallow malformed 
lists.  I observe that a list is either a Seq or a variable, and the 
tail of a list is a list.  So, I propose to modify the list production 
as follows:

LIST           ::= 'Seq(' TERM* ')' | 'Seq(' TERM+ ` | ` LIST ')' | Var

Best, Jos

Michael Kifer wrote:
> Sorry, my mistake. I corrected this:
> http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor-alt
> Had to introduce 1 more function, like in your semantics, but still
this is
> much easier to read, I believe.
> By the way, I realized that the syntax is not quite OK (for my
> because I do not treat Seq as a function symbol and so there is a
> possible confusion. I would prefer something like [[a b c d]] or <<a b
c d>>.
> This is not a big deal, however, since our presentation syntax is
> anyway and is used for examples/semantics only.
> On the second thought, it is not ambiguous, since our constants all
> like "..."^^iri and Seq does not look like that. Still, something like
> [[...] or <<...> seems preferable.
> One more thing.
> Apart from the simplified semantics, it is preferable to
> not treat Seq as a function symbol for other reasons as well. For
> if Seq is not a func sym, we will not need to add polyadic exceptions
> the syntax of BLD. Currently BLD has no such exceptions, but if we
> your proposed semantics then we would have to add exceptions.
> Another reason is that in your proposed XML syntax you do not treat
Seq as
> a function symbol. So, treating it as a function symbol in the
> syntax and the semantics and then not treating Sec as a function in
XML is
> not very pleasing.
> 	--michael  
>> Jos,
>> The current version says that nil is added to the domain,
>> but a version of your wording is more precise:
>> "the domain D of every RIF structure I contains an object nil".
>> Regarding the pair function, the idea is to keep it simple
>> in the manner of Lisp's s-expressions, as Michael mentioned
>> [the syntax allows Seq(1 2 | 3) as well as Seq(1 2 | Seq(...))]:
>> "every RIF structure contains a function pair: D x D -> D".
>> Michael,
>> Wouldn't you identify
>> I(Seq(t1 ... tn t))   = Iseq(I(t1), ..., I(tn), I(t))
>> with
>> I(Seq(t1 ... tn | t)) = Iseq(I(t1), ..., I(tn), I(t))?
>> Thanks to both,
>> Harold
>> -----Original Message-----
>> From: kifer@cs.sunysb.edu [mailto:kifer@cs.sunysb.edu] 
>> Sent: Friday, February 08, 2008 3:33 PM
>> To: Jos de Bruijn
>> Cc: Boley, Harold; RIF WG
>> Subject: Re: [BLD] comments on the semantics of lists 
>> Yes, the syntactic part of the proposal is fine, but the semantic is
>> incomplete and unnecessarily complex. I quickly put together an
>> alternative at
>> http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor-alt
>> The syntax part is the same there, but the semantics is different
>> (simplified and does not have undefined parts).
>> 	--michael  
>> Jos wrote:
>>> Harold,
>>> I had a closer look at your proposal for the semantics of lists in
>>> [1].  I have a few comments:
>>> The symbol nil is not defined.  It should probably be something like

>>> "the domain of every RIF structure I contains an object nil".
>>> The function pair is not defined.  It should probably be something
>> like 
>>> "every RIF structure contains a function pair: D x Dl -> Dl, where
>> is 
>>> a subset of D comprising the object nil and the range of pair".
>>> Apart from these two things, the proposal looks fine.
>>> Best, Jos
>>> [1] http://www.w3.org/2005/rules/wg/wiki/Core/List_Constructor
>>> -- 
>>> Jos de Bruijn            debruijn@inf.unibz.it
>>> +390471016224         http://www.debruijn.net/


Jos de Bruijn,        http://www.debruijn.net/
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw
Received on Saturday, 9 February 2008 18:45:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:45 GMT