Re: the super-safe list constructors (was Re: ACTION-761 - Lists in Core done)

> Sandro Hawke wrote:
> >>> I don't see why we are restricting to ground lists rather than using the
> >>> safety definition to limit use of the list operator.
> > 
> > There's some terminological confusion here.  No one is suggesting having
> > anything other than ground lists in Core.  Ground lists are lists which
> > (as stored and manipulated) do not contain empty slots with unification
> > semantics (aka unbound variables).  No one is suggesting lists in Core
> > should contain such odd things.
> 
> 
> We are talking here about RIF Core syntax. A term is ground iff it does
> not contain variables.
> If you mean something else with "ground", please use a different term.

Okay, I suggest we avoid using the term 'ground' with respect to lists,
since it's clearly causing more harm than good.

> > The text in the current Core spec (to my surprise) contain an additional
> > restriction, which is that the list construction operator syntactically
> > cannot be used with variables of any kind!  This is what this thread is
> > about.  I guess I'd call that a "super-safe list constructor", because
> > it gives you some extra guarantees, beyond even what strong safeness
> > gives you.
> > 
> > Dave and I are asking for justification for this super-safe list
> > constructor (and the GROUNDTERM, GROUNDUNITERM productions added to
> > support it).
> 
> Well, this was my understanding (and it seems also the understanding of
> others) from the resolution at the F2F [1]:
> 
> RESOLVED: Core will have immutable Ground Lists (no variables stored
> inside the list) with builtins generally paralleling the XPath
> "Sequence" functions (but this isn't a real XPath sequence, since it can
> be nested, etc). (Actual builtins to be settled in the future, soon) (If
> we have strong safeness in Core, then this stuff will be mostly useless
> in Core.)
> 
> 
> I actually still don't understand what "immutable" means. I also don't
> understand what "variables stored inside a list" are.
> 
> [1] http://www.w3.org/2005/rules/wg/meeting/2009-04-15


Okay, let's fall back to test cases....

test-case-1:

  PREMISE:   forall ?i (
                if ex:p(?i) then ex:q(List(ex:foo ?i))
             )
             ex:p(1)

  CONCLUSION:   ex:q(List(eg:foo 1))

I expect Core systems to handle that.  By the current draft, that's
unfortunately a negative syntax test.

What I understood we were ruling out with the resolution you quote was
rules like this:

test-case-2:

  PREMISE:     forall ?i (
                  if List(?i) = List(1) then passed
               )

  NON-CONCLUSION:  passed

That is, unifying list structures.  We don't want that in Core.  

Does that make more sense?

   -- Sandro

Received on Tuesday, 5 May 2009 14:03:11 UTC