On Jul 5, 2011, at 11:51 , Tamas Papp wrote:
I am very happy to learn about these things. Currently I am working on the algorithms and my main concern is to ensure correctness; speed is secondary at this point, but even though I am not optimizing, I want to keep my code optimizable later on.
My problem with the key argument is that it complicates the interface. I would like to use the same interface for sample statistics and random variables, eg currently in CL-NUM-UTILS and CL-RANDOM I have
(mean #(1d0 2d0 3d0)) ; => 2, a sample mean (mean (r-normal 2 1)) ; => 2d0, mean of a univariate normal distribution
If I had a :KEY argument, I would have to check that it is EQ to #'identity or not provided in methods for random variables.
But this is exactly where compiler macros can help. With the &key argument you keep a consistent (and useful) interface. The check whether to do away with a possible IDENTITY can be done in an appropriate compiler-macro.
APPLY is not a major concern for me at the moment, all of these functions have a fixed number of arguments (usually one or two). So compiler macros still look attractive: I guess I could just write them for the function I define (eg MAP1), with the understanding that if the user wants speed, he should stick to mapping with this function.
I also thought of the following possibility using runtime dispatch:
(defstruct (w/key (:constructor w/key (key object))) key object)
(defgeneric mean (object) (:method ((obj w/key)) (mean-w/key (w/key-object obj) (w/key-key obj))) (:method ((obj sequence)) (/ (reduce #'+ obj) (length obj))))
(defmethod mean-w/key ((obj sequence) key) (/ (reduce #'+ obj :key key) (length obj)))
(mean #(1 2 3)) ; => 2 (mean (w/key #'1+ #(1 2 3))) ; => 3
You can have your cake and eat it too. Why limit yourself?
Cheers -- Marco