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 <stass...@gmail.com> wrote: > Robert Smith <q...@symbo1ics.com> writes: > >> On Sat, Feb 23, 2013 at 4:19 PM, Stas Boukarev <stass...@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. _______________________________________________ alexandria-devel mailing list alexandria-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
