Re: Pre-alloc ListCell's optimization

Greg,

* Greg Stark (gsstark(at)mit(dot)edu) wrote:
> On Thu, May 26, 2011 at 8:52 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >  list_concat() does explicitly say that cells will
> > be shared afterwards and that you can't pfree() either list (note that
> > there's actually a couple cases currently that I discovered which were
> > also addressed in the original patch where I commented out those
> > pfree()'s).
>
> So in traditional list it would splice the second argument onto the
> end of the first list. This has a few effects that it sounds like you
> haven't preserved. For example if I insert an element anywhere in
> list2 -- including in the first few elements -- it's also inserted
> into list1.

Reading through the comments, it doesn't look like we expressly forbid
that, but it seems pretty unlikely that it's done. In any case, it
wouldn't be difficult to fix, to be honest.. All we'd have to do is
modify list2's head pointer to point to the new location. We do say
that list1 is destructively changed and that the returned pointer must
be used going forward.

> I'm not really sure we care about these semantics with our lists
> though. It's not like they're supposed to be a full-featured lisp
> emulator and it's not like the C code pulls any particularly clever
> tricks with lists. I suspect we may have already broken these
> semantics long ago but I haven't looked to see if that's the case.

It doesn't look like it was broken previously, but at the same time, it
doesn't look like those semantics are depended upon (or at least,
they're not tested through the regressions :).

Thanks,

Stephen