gmane.lisp.alexandria.devel

Re: Implementation of DELETE-FROM-PLIST

James M. Lawrence — 2013-02-27T02:10:09

Apologies to Robert for stealing his thunder.
_______________________________________________
alexandria-devel mailing list
alexandria-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-24T23:11:24

Looks good! Much cleaner/better.

-Robert

On Sun, Feb 24, 2013 at 6:30 AM, James M. Lawrence <llmjjmll< at >gmail.com> wrote:

Re: Implementation of DELETE-FROM-PLIST

Stas Boukarev — 2013-02-24T16:03:35

If striving for shortness:

(defun delete-from-plist (plist &rest keys)
  (dolist (key keys plist)
    (remf plist key)))

Re: Implementation of DELETE-FROM-PLIST

Zach Beane — 2013-02-24T15:56:36


I mention this for completeness and novelty, not for suitability:

  (defun sans (plist &rest keys)
    (let ((sans ()))
      (loop
        (let ((tail (nth-value 2 (get-properties plist keys))))
          ;; this is how it ends
          (unless tail
            (return (nreconc sans plist)))
          ;; copy all the unmatched keys
          (loop until (eq plist tail) do
                (push (pop plist) sans)
                (push (pop plist) sans))
          ;; skip the matched key
          (setq plist (cddr plist))))))

I don't think I've seen GET-PROPERTIES and NRECONC outside this
function.

I got it from here:
http://xach.com/naggum/articles/3247672165664225%40naggum.no.html

Zach

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-24T01:27:44

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:

Re: Implementation of DELETE-FROM-PLIST

Stas Boukarev — 2013-02-24T01:23:18

Well, those people should learn that it's not possible in
general. Particularly with lists, because of NIL.

What if the key you want to remove is NIL?

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.

There's no trading, delete-from-plistf is just a define-modify-macro for
delete-from-plist.

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-24T00:55:09

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.


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.


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 consistenc

Re: Implementation of DELETE-FROM-PLIST

Stas Boukarev — 2013-02-24T00:19:15

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.

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)))

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.

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

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-23T21:55:18

How is (:A 1 :D 4) wrong? There is no way to get it to just (:D 4) via
mutation when passing to a function. If we want to have just (:D 4),
we will need to either pass in

(nil nil <plist>)

which will give

(nil nil :D 4)

or we will need to encapsulate or box the value before going in, by
using something like https://bitbucket.org/tarballs_are_good/cl-ref .

All in all, it still returns (:D 4), but it just modifies as much of
the list structure as it can.

-Robert

On Sat, Feb 23, 2013 at 11:53 AM, Stas Boukarev <stassats< at >gmail.com> wrote:

Re: Implementation of DELETE-FROM-PLIST

Stas Boukarev — 2013-02-23T19:53:25

I don't see how (:A 1 :D 4) is useful, it's less wrong, but it's still
wrong.

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-23T19:46:59

Good style remarks, I suppose, which I can change.

On Sat, Feb 23, 2013 at 8:08 AM, Stas Boukarev <stassats< at >gmail.com> wrote:

The point of that was for more DWIMness.

Without it, we have:

CL-USER> (let ((x (list :a 1 :b 2 :c 3 :d 4)))
           (print (delete-from-plist x :a :b :c))
           x)

(:D 4)
(:A 1 :B 2 :C 3 :D 4)

And with it, we have:

CL-USER> (let ((x (list :a 1 :b 2 :c 3 :d 4)))
           (print (delete-from-plist x :a :b :c))
           x)

(:D 4)
(:A 1 :D 4)

If your typical mode of operation is to (setf x (delete-from...)),
then of course either are fine. If your goal is to use
DELETE-FROM-PLIST for its side effects, then I think the latter is
more useful. In fact, for really simple and efficient imperative
maintenance of a plist, just prepend (nil nil), and use the function
purely for mutation.

Cheers,

Robert

Re: Implementation of DELETE-FROM-PLIST

Stas Boukarev — 2013-02-23T16:08:55

Alexandria is not using :keyword style for LOOP.
DO in loop has an implicit progn, no need for an explicit one.
unless (prog1 ... (assert)) can be better expressed as
do (assert)
unless ... return cons
and finally (return nil) is not needed.

And I don't quite understand the purpose of
(unless (eq first plist)
        (setf (cddr plist)
              first))

Re: flatten depth param

Robert Smith — 2013-02-23T10:02:21

I apologize all, I stupidly didn't realize that there was a patch
already written.

Well, it can't hurt to have another implementation to compare with, right? :)

Cheers,

Robert

On Sat, Feb 23, 2013 at 1:57 AM, Robert Smith <quad< at >symbo1ics.com> wrote:

Re: flatten depth param

Robert Smith — 2013-02-23T09:57:21

Hello:

I've created a patch for this. The only difference is that instead of
flattening to a particular depth, it flattens by a particular number
of levels. I thought this was more in the spirit of FLATTEN. If we
want to flatten to a particular depth, it is a trivial computation.

I've attached a patch for the function, as well as tests.

Cheers,

Robert Smith

On Sat, Jan 26, 2013 at 6:12 AM, Nikodemus Siivola
<nikodemus< at >random-state.net> wrote:
_______________________________________________
alexandria-devel mailing list
alexandria-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-23T09:15:18

Attached is a proper patch.

-Robert

On Sat, Feb 23, 2013 at 1:09 AM, Robert Smith <quad< at >symbo1ics.com> wrote:
_______________________________________________
alexandria-devel mailing list
alexandria-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Implementation of DELETE-FROM-PLIST

Robert Smith — 2013-02-23T09:09:05

Hey:

Here's a destructive/non-consing version of DELETE-FROM-PLIST. I've
tested with (I think) all corner cases from the REPL, but I ought to
write tests proper.

The function is here http://tinyurl.com/adqkssu ;or the following huge
link, in case the last one is invalidated
https://bitbucket.org/tarballs_are_good/lisp-random/src/3db634111d35e788c6ea2f4a1b3ab38334e24cde/miscellaneous_exercises/delete-from-plist.lisp?at=default#cl-30
.

For simplicity or ease of review from an email client, I've pasted the
function at the end of this email.

Additionally, this function would make it pretty easy to write
DELETE-FROM-PLIST-IF{-NOT}, since the function to determine if a key
is bad is factored out. If one did write this function, then it would
be easy to define DELETE-FROM-PLIST in terms of it.

Let me know if there are any changes that should be made.

Cheers,

Robert Smith


;;;; from delete-from-plist.lisp

(defun delete-from-plist (plist &rest keys)
  "Delete all keys and pairs indicated by KEYS from the pli

Bug in gaussian-random

Andy Peterson — 2013-02-04T18:14:13

Hello,

Four months ago, I reported a bug in gaussian-random when either optional
parameter min or max is nil but not both are nil. The docstring has been
modified since then but the code is still the same and the bug remains. In
such a situation it is possible to enter an infinite loop.

This is easy to demonstrate by the call (gaussian-random 0 nil). You may
need to repeat the call a few times because the bug depends on the values
returned by the first call to the local function gauss.  An infinite loop
will occur if gauss returns a negative number.

I have attached a patch which fixes the bug.

Sincerely,

Andy Peterson
_______________________________________________
alexandria-devel mailing list
alexandria-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: Add SUBDIVIDE to alexandria

Robert Smith — 2013-01-29T05:37:51

Hello,

I finally conjured up a patch for SUBDIVIDE. Feel free to edit it. I wasn't
sure if using CHECK-TYPE was preferred style. Anyway, have fun.

The patch also exports the symbol SUBDIVIDE and also includes a battery of
tests.

Cheers,

Robert Smith

On Sat, Jan 26, 2013 at 6:14 AM, Nikodemus Siivola <
nikodemus< at >random-state.net> wrote:

_______________________________________________
alexandria-devel mailing list
alexandria-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel

Re: [PATCH] Added Scheme's LET as LET< at >

Nikodemus Siivola — 2013-01-27T15:17:06



Here's the thing: I think if you want to code Scheme style you should use
Scheme - or at least a library that tries to integrate schemey idioms into
CL. I do not believe Alexandria should try to incorporate scheme idioms -
not because they're bad, but because they're not CL idioms.

I find named-let mostly useful for quick initial ports of code written in
Scheme.




I don't really care if people think it a matter of taste or objective
truth. The fact remains that I'm opposed to single-character suffixes or
prefixes denoting variants of standard operators in general purpose
libraries. (I'm much more lenient about special purpose libs.)




Depends. Labels, do, dolist, do*, loop, tagbody, mutually recursive
toplevel defuns, dotimes, prog, y-combinator. Whatever seems most
appropriate for the task at hand.

Re: [PATCH] Added Scheme's LET as LET< at >

Pierre Thierry — 2013-01-27T14:25:45

Scribit Nikodemus Siivola dies 26/01/2013 hora 16:21:

The thing is, if you want to code with a scheme style, you'll use
named lets very often, so it ought to have a rather short name. Why
the issue with let< at >, for my curiosity's sake? (for me, < at > looks a lot
like a spiral or something like an ongoing loop)


Ever since I understood recursion, I've always found this way more
readable than anything else, to what would you usually rewrite a named
let?

Curiously,
Pierre

Re: More open development

Pierre Thierry — 2013-01-26T18:39:33

Scribit Nikodemus Siivola dies 26/01/2013 hora 19:24:

Do you think that having an unstable-like (as in Debian) version of
alexandria where there are none of the alexandria rules would be
detrimental to alexandria?

Curiously,
Pierre