gmane.lisp.alexandria.devel

Re: [Patch]: Fix an example in the docstring ofiota.

Stas Boukarev — 2012-05-15T21:35:13


Thinking about it some more,
(alexandria:iota 5 :start 1.0 :step #c(0 2)) =>
(1.0 #C(1.0 2.0) #C(1.0 4.0) #C(1.0 6.0) #C(1.0 8.0))
doesn't look right.

Re: [Patch]: Fix an example in the docstring ofiota.

Stas Boukarev — 2012-05-15T21:20:08

As I look at it more, it doesn't appear to be a problem, since it
conforms to the definition of contagion in CL.

Re: [Patch]: Fix an example in the docstring ofiota.

Stas Boukarev — 2012-05-15T21:15:58


Another problem seems to be with contagion when used with complex
numbers:
(alexandria:iota 5 :start 1 :step #c(1 2)) =>
(1 #C(2 2) #C(3 4) #C(4 6) #C(5 8))

[Patch]: Fix an example in the docstring of iota.

Stas Boukarev — 2012-05-15T20:57:22

An example in the docstring of iota was
(iota 4) => (0 1 2 3 4)
while it should've been
(iota 4) => (0 1 2 3).

Split up Alexandria into an additionalexperimental package?

Tobias C Rittweiler — 2012-04-26T09:43:44

What is a good way to handle new additions to Alexandria that
are not fully fledged out yet?

As Hans noticed himself over this week, it usually takes
an incredible amount of time and effort to come up with
something with complete semantics. Time is a scarce resource,
and even if it was not, only experience and actual usage will
discover edges cases.

Common Lisp itself has been tried out and implemented many
times during the standardization process itself which is one
of the reasons it's engineered as well as it is.


What about providing an :ALEXANDRIA.EXPERIMENTAL
package that uses :ALEXANDRIA? New additions
go into the experimental package which is advertised
not necessarily to be fully backwards compatible.

People can explicitly :IMPORT-FROM that package (which
will continue to work even when the symbol moves from there
into :ALEXANDRIA, assuming no incompatible changes have been
made.)

T

Re: DESTRUCTURE-CLAUSES -alexandria_destruct#9CF676.diff (1/1)

Tobias C Rittweiler — 2012-04-26T09:16:51

In article <1335431200.3991.0.camel< at >cathai>,
 Stelian Ionescu <sionescu< at >cddr.org> wrote:


Ah, true. I forgot about that. That answers my question in the other 
mail.

T

Re: DESTRUCTURE-CLAUSES -alexandria_destruct#9CF676.diff (1/1)

Tobias C Rittweiler — 2012-04-26T09:15:25

In article 
<CADow0CpTq8ns8xx065Uk7P92-w98b6njBkzK4f9qUffh3iaqpw< at >mail.gmail.com>,
 Nikodemus Siivola <nikodemus< at >random-state.net> wrote:


Yes, that is true. I also regularly use the following macro in
macro definitions:

;;; This is a macro for sake of nicer indentation of the format control.                     
(defmacro assert-no-duplicates (list (&key test key) &body 
(format-control . format-args))
  "If LIST contains duplicates, an error is signaled. FORMAT-CONTROL,                          
   
and FORMAT-ARGS are passed to ERROR along an enumeration of the                             
   
duplicated items."
  `(%assert-no-duplicates ,list ,test ,key ,format-control (list 
,< at >format-args)))


(defun %assert-no-duplicates (list test key format-control format-args)
  (let* ((test    (if test (ensure-function test) #'eql))
         (no-dups (remove-duplicates list :test test :key key)))
    (unless (= (length list) (length no-dups))
      (error "~< at ><~? ~:_Duplicates are:~:_ ~:I~{~S~^, ~:_~}~:>"
            format-control format-args
            (dolist (x no-dups list)
              (setq list (remove (if key (funcall key x) x) list
                                 :count 1 :test test :key key)))))))

E.g.

  (defmacro defpackage (name &body clauses)
    (assert-no-duplicates clauses (:key #'car)
       "Found duplicates in the clauses passed to ~S."
       `(defpackage ,name))
    (destructure-clauses clauses
        ((:uses &rest uses)
          ...)
      (expand-defpackage uses ...)))

Do you want me to provide that as a patch, too?



I don't know. It invents unprecedented syntax for a not really common
case. And the manual way doesn't seem that bad:

  (destructure-clauses clauses
      ((:foo &rest xs1)
       (:bar &rest xs2)
       ...)
    (let ((xs (append xs1 xs2)))
      ...))

 

That one seems useful on its own. How comes you think the merging
of clause parameters is anything but a rare occasion anyhow?


T

T

Re: DESTRUCTURE-CLAUSES - alexandria_destruct#9CF676.diff (1/1)

Stelian Ionescu — 2012-04-26T09:06:40

Exactly: CL:DEFPACKAGE allows repeated :export clauses and requires them
to be merged(appended)

Re: DESTRUCTURE-CLAUSES - alexandria_destruct#9CF676.diff (1/1)

Nikodemus Siivola — 2012-04-26T08:41:54


Nice!

Unless I misread this, duplicate clauses cause the earlier one to be
discarded? Signaling an error instead might be better, though a fairly
common pattern might also be served by special casing clauses of the
form

  (:keyword &append stuff)

or something like that, which would cause duplicate clauses to have
their contents merged.

Or maybe that should be factored into a separate function MERGE-ALIST,
for preprocessing the clauses?

 function MERGE-ALIST keys alist &optional (merge #'append)

...or something along those lines?

Cheers,

 -- Nikodemus

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

Re: Proposed addition of temporary file creation utilities

Daniel Herring — 2012-04-26T00:47:19

What you describe is very similar to the mktemp command on most linux 
systems.  Use the TMPDIR environment variable, create a directory, etc.

http://www.mktemp.org/manual.html
http://www.gnu.org/software/coreutils/manual/html_node/mktemp-invocation.html

http://en.wikipedia.org/wiki/TMPDIR


Whether these directories are somewhere in a home directory or collected 
under /tmp is irrelevant to security -- permissions in either place can be 
toggled.  Collecting them under /tmp is convenient if "root" wants to blow 
them all away at once, and many systems are set up to automate such 
cleanup.

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

Re: EXTREMUM

Tobias C Rittweiler — 2012-04-25T14:21:48

In article 
<CADow0CrM=mrumUUTe11ZxgT594Sz41PApPYg--y+SBb8jzqOXQ< at >mail.gmail.com>,
 Nikodemus Siivola <nikodemus< at >random-state.net> wrote:


I agree it's pointless. Why not just return NIL? (Or possibly
(values <element> T) in case an extremum was found.)
FIND, FIND-IF just return NIL, too, never minding the ambiguity.
And EXTREMUM can be thought of a special case of FIND.

T

DESTRUCTURE-CLAUSES -alexandria_destruct#9CF676.diff (1/1)

Tobias C Rittweiler — 2012-04-25T13:47:04

I was pleased to discover that DESTRUCTURING-CASE made it into
Alexandria meanwhile. Very nice! This allows me to share the
little gem that I'm attaching with this posting. It's a handy
macro to make writing macros like DEFPACKAGE, DEFGENERIC of
DEFREADTABLE easy like a breeze.

Happy to be giving back again! :-)

T
diff --git a/macros.lisp b/macros.lisp
index 4450435..0d4b9e9 100644
--- a/macros.lisp
+++ b/macros.lisp
< at >< at > -303,4 +303,76 < at >< at > Example:
   (setf (documentation name 'function) (documentation 'destructuring-case 'function)))
 
 
+;;; DESTRUCTURE-CLAUSES
 
+(defmacro destructure-clauses (clauses patterns &body body)
+  "Utility macro to conveniently destructure DEFPACKAGE like clauses.
+
+     clauses  ::= clause*
+     clause   ::= (keyword . list)                  ; e.g. (:FOO 1 :K 2)
+
+     patterns ::= pattern*
+     pattern  ::= (keyword . ordinary-lambda-list)  ; e.g. (:FOO N &KEY K)
+
+The CAR of each clause in CLAUSES will be tried to be matched against
+the CAR of each pattern in PATTERNS. If a match is found, the CDR of
+the matched pattern is interpreted as an ordinary lambda list and its
+parameters are bound to the values provided by the CDR of the clause.
+
+When all CLAUSES are processed, BODY will be executed with all the
+parameters of the matched patterns bound appropriately. Notice that
+parameters must hence be named distinctively in each pattern.
+
+Example:
+
+  (defmacro defpackage (name &body clauses)
+    (destructure-clauses clauses
+        ((:use &rest uses)
+         (:nicknames &rest nicknames)
+         (:export &rest exports)
+         ...)
+      (expand-defpackage name uses nicknames exports ...))
+
+Implementation note:
+
+  That a pattern consists of ordinary lambda list and not of
+  destructuring lambda lists is a /shortcoming/ of the current
+  implementation. Patches are welcome.
+"
+  (multiple-value-bind (pattern-table vars n-vars)
+      (loop for pattern in patterns
+            for vars   = (ordinary-lambda-list-parameters (cdr pattern))
+            for n-vars = (mapcar #'make-gensym vars)
+            collect (cons pattern (list vars n-vars)) into pattern-mappings
+            append vars   into all-vars
+            append n-vars into all-n-vars
+            finally
+            (return (values (alist-hash-table pattern-mappings)
+                            all-vars
+                            all-n-vars)))
+    (with-unique-names (clause)
+      `(let ,n-vars
+         (dolist (,clause ,clauses)
+           (destructuring-ecase ,clause
+             ,< at >(loop for p in patterns
+                     for (pattern-vars pattern-n-vars) = (gethash p pattern-table)
+                     collect `(,p ,< at >(loop for var   in pattern-vars
+                                          for n-var in pattern-n-vars
+                                          collect `(setq ,n-var ,var))))))
+         (let ,(mapcar #'list vars n-vars)
+           ,< at >body)))))
+
+(defun ordinary-lambda-list-parameters (ordinary-lambda-list)
+  "Return a list of all parameter names in ORDINARY-LAMBDA-LIST."
+  (flet ((optional-parameter-name (spec)
+           (car spec))
+         (key-parameter-name (spec)
+           (second (first spec))))
+    (multiple-value-bind (reqs opts rest keys aok auxs)
+        (parse-ordinary-lambda-list ordinary-lambda-list)
+      (assert (null aok)  () "&ALLOW-OTHER-KEYS not supported.")
+      (assert (null auxs) () "&AUX not supported.")
+      (append reqs
+              (mapcar #'optional-parameter-name opts)
+              (ensure-list rest)
+              (mapcar #'key-parameter-name keys)))))
\ No newline at end of file
diff --git a/package.lisp b/package.lisp
index babeb95..a025cc7 100644
--- a/package.lisp
+++ b/package.lisp
< at >< at > -240,4 +240,5 < at >< at >
    #:destructuring-case
    #:destructuring-ccase
    #:destructuring-ecase
+   #:destructure-clauses
    ))
diff --git a/tests.lisp b/tests.lisp
index e218113..51ea8ca 100644
--- a/tests.lisp
+++ b/tests.lisp
< at >< at > -1856,3 +1856,47 < at >< at >
             (when err
               (incf n))))))
   13)
+
+(deftest destructure-clauses.1
+    (let ((+clauses+ '((:required-1 :R1)
+                       (:required-n :R2 :R3 :R4)
+                       (:optional-0)
+                       (:optional-1 :O2)
+                       (:key-0)
+                       (:key-1 :KEY2 :K2)
+                       (:key-n :KEY3 :K3 :KEY4 :K4)
+                       (:required+optional-0 :R5)
+                       (:required+optional-1 :R6 :O4)
+                       (:required+key :R7 :R8 :KEY5 :K5))))
+      (destructure-clauses +clauses+
+          ((:required-1 req1)
+           (:required-n req2 req3 req4)
+           (:optional-0 &optional (opt1 :O1))
+           (:optional-1 &optional opt2)
+           (:key-0 &key (key1 :K1))
+           (:key-1 &key key2)
+           (:key-n &key key3 key4)
+           (:required+optional-0 req5 &optional (opt3 :O3))
+           (:required+optional-1 req6 &optional opt4)
+           (:required+key req7 req8 &key key5))
+        (values
+         (list req1)
+         (list req2 req3 req4)
+         (list opt1)
+         (list opt2)
+         (list key1)
+         (list key2)
+         (list key3 key4)
+         (list req5 opt3)
+         (list req6 opt4)
+         (list req7 req8 key5))))
+  (:R1)
+  (:R2 :R3 :R4)
+  (:O1)
+  (:O2)
+  (:K1)
+  (:K2)
+  (:K3 :K4)
+  (:R5 :O3)
+  (:R6 :O4)
+  (:R7 :R8 :K5))
\ No newline at end of file

Re: Proposed addition of temporary file creation utilities

Stelian Ionescu — 2012-04-25T13:35:52

To achieve safety, the umask must be specified on creation. If cl:open
doesn't allow that, then it's effectively useless for the purpose of
properly creating temporary files



The goal should be to protect, as much as possible, also against
malicious programs running under the same UID and randomizing file and
directory names, as opposed to using well-known names, is very useful in
that regard

Re: Proposed addition of temporary file creationutilities

Hans Hübner — 2012-04-25T13:05:19

If the Lisp implementation provides a means to specify the file
permissions to cl:open, then that would be how it should be done for
temporary files, too.  I do not understand what you mean by "quite the
opposite" here.  Is there anything in the proposed API that makes it
impossible to specify file permissions, if so supported by the
underlying implementation?


Yes.  As it does.


Windows and OSX do better than Unix by default in that they have user
specific temporary directories, and this is all that we're discussing
anyway.  The only isolation that one can hope to have is on a per-user
level, i.e. one may want to prevent that a process running under a
some user ID can access a (temporary or non-temporary) file created by
a process running under a different user ID.  By making the
user-specific temporary directories inaccessible to other user IDs,
this goal is neatly achieved.

-Hans

Re: EXTREMUM

Nikodemus Siivola — 2012-04-25T13:04:59


So, what about the NO-EXTREMUM thing?

I think it's good that the behaviour specified, instead of depending
on the PREDICATE and REDUCE, but an an interface NO-EXTREMUM +
CONTINUE is terrible: unless you handle the error right around the
call site, it's pointless, since no-one higher up the call stack can
know for sure where the error came from. At the call site it is overly
verbose and inefficient:

 (handler-bind ((no-extremum #'continue))
    (extremum ...))

I would much like to remove mention of the restart from the docstring,
and add &KEY DEFAULT instead:

    (extremum ... :default nil)

would provide the same behaviour as invoking CONTINUE. Since you
obviously actually use this thing, any comments?

Cheers,

 -- Nikodemus

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

Re: Proposed addition of temporary file creation utilities

Stelian Ionescu — 2012-04-25T12:42:17


Quite the opposite, the permissions must be specified at creation time,
otherwise it's useless



Old habits(a.k.a. Unix tradition). Distributions are slowly changing
this, but a Lisp library should work in any case



That's not how they do it. Windows and OSX have a user-specific
temporary directory and applications usually create a subdirectory of
their own but with a well-known name: see documentation for
NSTemporaryDirectory, for example

Re: Some number patches

Nikodemus Siivola — 2012-04-25T12:44:58


(Didn't check your code yet, this is just based on the names.)

DIVF and MULF I think I'm fine with.

Though I share most of Tamas' reservations re. POSITIVEP and
NEGATIVEP, but acknowledge that they form a good symmetry with the
NON-*-P versions -- so I think I'm fine with those going in as well.
If they go in, they should be synonyms for PLUSP and MINUSP, though --
not subtly different.

As for NON-*-P ... I kind of like them. While COMPLEMENT works, I'm
pretty glad we have REMOVE-IF-NOT, instead of being forced to write

  (remove-if (complement #'foop) ...)

Similarly, I think (NON-NEGATIVE-P X) is cleaner to read than (NOT
(MINUSP X)) -- though the cognitive cost difference it pretty trivial.

Thinking about them.


Not for the asking, no.

If you provide several high quality patches and display the kind of
judgement we're looking for, yes, eventually.

Cheers,

 -- Nikodemus

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

Re: EXTREMUM

Nikodemus Siivola — 2012-04-25T12:30:25


Pushed a version. Can you verify that it is what you wanted, and
performs acceptably?

Cheers,

 -- Nikodemus

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

Re: Proposed addition of temporary file creationutilities

Hans Hübner — 2012-04-25T10:26:23

Nikodemus,

I've already packaged the functionality into a separate library:
http://netzhansa.com/temporary-file.html - I have some things to clean
up and improve before releasing it into Quicklisp.

The random state in that implementation is protected by a lock - The
overhead should be negligible, given that the lock is grabbed in the
context of a file operation.

Dealing with the umask has no place in this library.  "umask" is a
system-specific concept, and file security is something that is
orthogonal to temporary files.  If an application wishes to give its
temporary files different permissions than other files that it
creates, it should do so explicitly.

And besides, why put temporary files into a shared directory in the
first place?  The right way to deal with possible issues in this
respect is to create an application specific temporary directory that
is completely protected before starting the application, and
communicating that directory to the application by the way of the TEMP
or TMPDIR environment variable.  That is how Windows and OSX do it,
and it is much better than trying to protect files in a shared /tmp/
directory.  As if we did not have a hierarchical file system for a few
decades.

That said, I'm not particularly fond of having a separate library for
such a simple thing and I'd be glad to see it be merged to some other
utility type library that is not restricted to certain styles of
system interfaces (i.e. POSIX).

-Hans

On Wed, Apr 25, 2012 at 6:11 AM, Nikodemus Siivola
<nikodemus< at >random-state.net> wrote:

Re: Proposed addition of temporary file creationutilities

Nikodemus Siivola — 2012-04-25T10:11:35

I'm coming on the side of saying that this has a place in Madeira,
(first version of which I'm releasing before the end of May.)

Madeira can deal with the umask and thread-safety of *random-state*,
whereas Alexandria has so far resisted unportable or implementation
specific code -- and dealing with those two requires that.

Umask could be degreed to simply be the process umask, which would be
suboptimal but acceptable, but thread-safety is more serious -- though
I suspect that parallel RANDOM calls should at worst produce degraded
quality of random numbers, not corruption or errors, but every time
someone assumes "this can't cause serious issues" a kitten dies, so...

Cheers,

 -- nikodemus

EXTREMUM

Tobias C Rittweiler — 2012-04-25T09:15:59

The cl-utilities library contains one function which cannot be
found in alexandria that necessity pops up every now and then:

  Returning the maximum (or minimum) element in a sequence
  with respect to an arbitrary calculation involving the elements.

I.e.

  (elt (sort (copy-sequence <SEQUENCE>) #'< :key <FUNCTION>) 0) ; or #'>

except doing it more efficiently.

CL-UTILITIES calls this function EXTREMUM. (It also provides a couple
of more functions along the lines to cover some edge cases.)

The code can be found here:
 
http://common-lisp.net/viewvc/cl-utilities/cl-utilities/extremum.lisp?rev
ision=1.10&view=markup

As the code is Public Domain, it could just be moved as is.


I find no other use of cl-utilities and would like to see it
become entirely obsolete.

T