RE: [BLD] comments on the semantics of lists

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

Best,
Harold


-----Original Message-----
From: Jos de Bruijn [mailto:jos1997@gmail.com] On Behalf Of Jos de
Bruijn
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

Michael,

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
semantics),
> 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
ambiguous
> anyway and is used for examples/semantics only.
> 
> On the second thought, it is not ambiguous, since our constants all
look
> 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
instance,
> if Seq is not a func sym, we will not need to add polyadic exceptions
to
> the syntax of BLD. Currently BLD has no such exceptions, but if we
adopt
> 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
presentation
> 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
RIF
>>> [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
Dl
>> 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/
>>
>>
> 
> 
> 

-- 
                          debruijn@inf.unibz.it

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 UTC