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

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

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

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

Received on Tuesday, 5 May 2009 12:17:59 UTC