W3C home > Mailing lists > Public > public-rif-wg@w3.org > May 2009

"ground" lists

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 01 May 2009 11:33:36 -0400
To: Dave Reynolds <der@hplb.hpl.hp.com>
cc: Jos de Bruijn <debruijn@inf.unibz.it>, RIF <public-rif-wg@w3.org>
Message-ID: <5404.1241192016@ubehebe>
> Jos de Bruijn wrote:
> 
> >>>> [*] By the way, is this rule set in RIF Core? During the f2f discussion
> >>>> on "grounded lists" in the core I found it hard to follow on the phone
> >>>> what people were meaning by grounded lists.
> >>> No. We were talking about ground lists, and ground=no variables.
> >> My confusion was whether we meant the resulting lists are ground i.e.
> >> are we just ruling out prolog lists with unbound variables in them or
> >> blocking all "runtime" construction of lists. You are saying the later
> >> which was my impression also.
> >>
> >> In that case Lists are completely useless in Core.
> >>
> >> Am I allowed to have a DTB builtin for constructing lists? I remember
> >> this being discussed at the f2f but couldn't follow the argument against
> >> it.
> > 
> > Yes, you can use the builtins. Because of this the lists are not useless
> > and, also, your system is not guaranteed to terminate.
> 
> So why the restriction to ground lists? Could we not just define safety 
> over List terms analogously to externals?
> 
> As far as I can see I can translate any usage of List with variables to 
> an equivalent using externals:
> 
>     ... List(?x ?y) ...
> 
> =>
> 
>     And( ... ?Z ...,
>        ?Z = func:insert-before(func:insert-before(List(), 0, ?y), 0, ?x))
> 
> The syntactic restriction to ground List elements doesn't seem to be 
> serving any purpose.

During the meeting, I understood "ground lists" to mean lists that store
Consts, not unbound Vars.  That is, we decided they should not be like
Prolog's weird (but fun) lists.  (In Prolog terminology, a ground list
is one that doesn't have any unbound variables in it; outside of prolog,
that's just 'a list', since XPath, Perl, Java, etc, never have unbound
variables in lists.)

Beyond that, there's the question about whether the cons operator
("List") should be a part of the syntax of the language, or just a
builtin.  If it's a part of the syntax of the language, should it be
defined as:

  LIST ::= 'List(' TERM* ')' | 'List(' TERM+ '|' TERM ')'

or something like:

  LIST ::= 'List(' Const* ')' | 'List(' Const+ '|' TERM ')'

I don't know if anyone really wanted the second form here.  As you point
out, it doesn't really buy you anything, since you can still do what you
want with builtins.  So I hope no one is seriously considering it.  I'm
not sure where in the state of flux the various documents are now to
know which view they reflect.

If this is going to be confusing, I wouldn't be opposed to having lists
be purely a DTB and SWC matter; I don't see Core/BLD/PRD needing to say
anything about them.  (That said, I'd need some help getting the math
right in their definition in DTB, if we went that route.)

     -- Sandro
Received on Friday, 1 May 2009 15:33:46 GMT

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