python list handling and Lisp list handling
dr.mtarver at ukonline.co.uk
Sat Apr 25 01:32:26 CEST 2009
On 24 Apr, 19:54, Arnaud Delobelle <arno... at googlemail.com> wrote:
> Mark Tarver <dr.mtar... at ukonline.co.uk> writes:
> > Ah; so this
> > def cons (x,y):
> > return [x] + y
> > is not accurate?
> Depends what you mean by accurate!
> in lisp, if you do:
> (setq a '(1 2))
> (setq b (cons 0 a))
> (rplaca a 3)
> a is now (3 2)
> b is now (0 3 2)
> In Python, if you do:
> a = [1, 2]
> b = cons(0, a) # with your definition of cons
> a = 3
> a is now [3, 2]
> b is now [0, 1, 2]
> So in this respect, it is not accurate. But that's because Python lists
> are vectors not conses.
Thanks for that.
OK; I think I get it. RPLACA and RPLACD are part of the id of Common
Lisp which I rarely contemplate. However what it seems to be is that
the difference is this. Lisp operates a destructive operation like
RPLACA in such a way that RPLACA on a global G not only changes G, but
all globals that reference G. Python on the other hand has a
destructive operation a = .... which acts a bit like RPLACA but
whose change is local to the global changed. I take it that this is
because Python essentially copies the list, creating a brand new
vector rather than playing with pointers. Is that more or less it?
Which brings me to my next question. Assuming that we ban the use of
destructive operations like a = ... Lisp's RPLACA and all the
rest. Assuming the following Python encodings, and ignoring questions
of performance, would Python and Lisp lists then be observationally
indistinguishable? i.e. would these then be fair encodings?
def car (x):
def cdr (x):
def cons (x,y):
return [x] + y
More information about the Python-list