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,

I guess, it is time to reveal the secret: with signatures we actually do
have something what amounts to sorts :-)

But I do not think we should introduce something special for lists (in
terms of sorts).


	--michael  

> 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 19:52:55 UTC