Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!umich!yale!quasi-eli!cs.yale.edu!newsbase!duchier
From: duchier@cs.yale.edu (Denys Duchier)
Newsgroups: comp.lang.prolog
Subject: Re: Lists (was Arrays) in Prolog
Message-ID: <DUCHIER.90Oct4112110@albania.cs.yale.edu>
Date: 4 Oct 90 15:21:10 GMT
References: <1238@ecrc.de> <1990Sep19.075314.14372@irisa.fr> <1403@ecrc.de>
	<34487@cup.portal.com> <6009@hplabsz.HPL.HP.COM>
Sender: news@cs.yale.edu
Reply-To: duchier-denys@cs.yale.edu
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 30
Nntp-Posting-Host: albania.ai.cs.yale.edu
In-reply-to: kirshenb@hplabsz.HPL.HP.COM's message of 4 Oct 90 00:00:12 GMT

In article <6009@hplabsz.HPL.HP.COM> kirshenb@hplabsz.HPL.HP.COM (Evan Kirshenbaum) writes:
 >   I called ..X a splice (... was equivalent to .._), and it was an
 >   actual object in the sequence (although you couldn't get one outside
 >   of a sequence).  Unifying a sequence that contained splices was
 >   possibly nondeterministic, but was reasonably easy to implement.
 >   Multiple solutions were obtained on backtracking.  This allowed you to
 >   define
 >	   append(Xs,Ys,[..Xs,..Ys]).
 >	   member(X,[...,X,...]).
 >	   last(L,[...,L]).

This is not exactly a novel idea.  In PLANNER [Hewitt circa 67 -- I
think] it was called a segment variable.  The problem with segment
variables is that unification not only may have several solutions, but
occasionally infinitely many of them.  Consider:

	[..X foo] to be unified with [foo ..Y]

The set of unifiers for this example is:

	{ X = Y = [] }
	{ X = Y = [foo] }
	{ X = Y = [foo foo] }
	{ X = Y = [foo foo foo] }
	...

Nonetheless, segment variables are very convenient, and I still use
them in my work.

--Denys