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.

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


Best, Jos

[1] http://www.w3.org/2005/rules/wg/meeting/2009-04-15


> 
> Jos answers (with me doing square-brackets edit):
> 
>> An argument for having only [a super-safe list constructor] is that
>> implementations can view [lists] as being atomic, and can leave their
>> manipulation up the built-ins.  So, implementations do not need to
>> have the machinery to deal with constructed terms and can restrict
>> themselves to variables and constants.
> 
> I don't see that.  The implementation can just call the builtins to
> assemble the list in any case.  (Or, if you're thinking about a strict
> translation-only implementation, it will just rewrite list-construction
> expressions into external calls, if there's no suitable list structure
> in the target language.)
> 
> Adrian?  Harold?  Does anyone have a compelling reason for having only
> the super-safe list constructor?  Was it just a misunderstanding?
> 
> I'm okay with just having the list constructor be a builtin to sidestep
> this whole issue.  In many ways, it's a much simpler design.  The only
> drawback I see is that it might be be difficult to formally specify how
> lists in BLD are extended to contain unbound variables.  (But maybe
> that's okay; I don't know if having lists contain unbound variables is
> important, as much as I love it as a trick in Prolog programming.  I'd
> be willing to do without them, and just have lists in BLD be the same as
> lists in Core.)
> 
>       -- Sandro

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller