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

[Robert Smith]

Fair enough, I feel sufficiently convinced.

If only we could construct NIL from a cons cell, eh?

Thanks,

Robert

On Sat, Feb 23, 2013 at 5:23 PM, Stas Boukarev <stassats at gmail.com> wrote:
> Robert Smith <quad at symbo1ics.com> writes:
>
>> 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.
> Well, those people should learn that it's not possible in
> general. Particularly with lists, because of NIL.
>
>> 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.
> What if the key you want to remove is NIL?
>
>>> 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.
> There's no other way to obtain the correct results otherwise. Having it
> to work in 99% is worse than having it not to work at all, because
> people might forget about the remaining 1% case more easily. So you end
> up with doing extra work which has no use. The goal is simplicity, not
> having to memorize in which cases it's alright and which it's not. Just
> use the return value and be merry.
>
>>> 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?
> There's no trading, delete-from-plistf is just a define-modify-macro for
> delete-from-plist.
>
> --
> With best regards, Stas.