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.

You are right. But I do not know if we should prevent malformed lists or not.
In LISP they are used all the time, and in Prolog to a lesser extent.
The argument can go either way, and I am not sure of my preference.


	cheers
	  --michael  


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

Received on Saturday, 9 February 2008 19:49:03 UTC