[alexandria-devel] Implementation of DELETE-FROM-PLIST

[Robert Smith]

On Sat, Feb 23, 2013 at 4:19 PM, Stas Boukarev <stassats at gmail.com> wrote:
> It's wrong because it's completely useless, why would anyone use
> delete-from-plist without using the value returned by it, if the
> original list it modifies has the wrong result? Having to prepend two
> NILs is just bogus.

1. Because some people like or prefer to modify data structures
(especially when you have elaborate data structures), and not
bindings.

2. Having to prepend two NILs is fine I think. Yes it is hacky, but I
don't see any inherent issue with it. It just establishes a (few)
conses that act as the "head" or "entry point" to the list.

> Although, that's not true that there's no way to have (:D 4), but the
> problem just shifts to when it deletes everything and it's a NIL:
>
> (unless (eq first plist)
>   (psetf (car plist) (car first)
>          (cdr plist) (cdr first)))

I suppose you're correct here. I was implicitly assuming that we would
want to never modify the CAR, but that is a sort of useless
assumption.

> But that part shouldn't be in alexandria (or any sane library, for that
> matter) either way, because it encourages erroneous usage, seemingly
> doing the right thing, but breaks when it comes to returning NIL.

I don't think it's erroneous. We aren't conflating the ideas of
modifying a data structure and modifying a binding. By not doing that
extra mutation, we rely on the user to "finish the job" by re-setting
their variable to the new value.

The only thing "weird" about it is that there are a lot of Lisp
functions which don't "completely" mutate the data structure, and
expect the user to modify the binding. As far as I can tell, then, the
really only argument against such a thing is "that's not how other CL
functions work, so for consistency's sake, we shouldn't either."
Unless I'm missing some point.

> And there's alexandria:delete-from-plistf for people who are afraid of
> an extra SETF.

In this, we are trading a purely functional (i.e., non-special/macro)
solution for a macro solution. Doesn't that go against the grain of
the prevalent ideology of Lisp?

Cheers,

Robert