Re: [BLD] comments on the semantics of lists

Harold,

I don't understand what you mean with "bound".

Interpretations assign variables to elements of the domain.  If you want 
to make sure that variables are assigned to lists, then you need to 
define a subset of the domain, which is the set of lists, and modify the 
interpretation of sequence and tail accordingly.  I did something like 
that in my proposed modification of your original proposal somewhere 
earlier in this thread.  However, I guess it is not really necessary.

My proposed update of the LIST production ensures that malformed lists 
cannot be derived.  I think this was the biggest concern.

Best, Jos

Boley, Harold wrote:
> Jos, Var could be bound to a non-LIST, 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