Given the function (filter func list) which
applies func to each element of list and
returns a list of the non-nil results, and
given a desire to name it something other
than filter, what does everyone think would
be the best name for this function?
(This is from the recent thread whose subject
line is "looking for a more elegant solution
to a simple problem".
A more general question is what percentage of
our programming time should we spend naming
functions? If we don't spend enough, the names
might waste our time later, but if we spend too
much, our time has already been wasted. Where
is the best compromise between those extremes?
From: Steven E. Harris
Subject: Re: Function names and "filter" function
Date:
Message-ID: <q67wudzoeld.fsf@raytheon.com>
········@yahoo.com (Eric Smith) writes:
> Given the function (filter func list) which applies func to each
> element of list and returns a list of the non-nil results, and given
> a desire to name it something other than filter, what does everyone
> think would be the best name for this function?
How about `collect'?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
I use 'filter' very frequently, about once per 100 lines of code I
write. I try to write a utility function for anything I do more than
twice, so I have a very low threshold (in the spirit of bottom-up
programming).
I don't put much thought into my lisp function names- I think of lisp
names like GUI icons: They should take little screen real-estate and
look distinctive (Heck, I still don't know what the icon for windows
xemacs is supposed to be, but I recognize it instantaneously.) I force
myself to keep all function names to no more than ~8 characters. I can
always check the defstring if I forget the function and its behavior
isn't obvious from context.
So 'filter' works fine as a name for me.
On Wed, Jul 30, 2003 at 09:16:23PM -0700, Conrad Barski wrote:
> I force myself to keep all function names to no more than ~8
> characters.
I think this is a bad limitation to keep. Longer function names make
for self-documenting code, and with name-completion, they aren't hard to
type.
> So 'filter' works fine as a name for me.
Except that 'filter' already has a widely-used definition in
programming, and it's not (remove nil (mapcar fn list)).
;; simple naive filter
(defun filter (fn list)
"Return a new list with the elements of list that satisfy fn."
(cond ((endp list)
nil)
((null (funcall fn (first list)))
(filter fn (rest list)))
(t
(cons (first list) (filter fn (rest list))))))
(filter #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
;; also see: remove-if-not
(remove-if-not #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
;; what was discussed in the thread
(defun map-and-drop-nils (fn list)
"Return a new list created by mapping fn across each element of
list and omitting any NIL values from the final result list."
(if (endp list)
nil
(let ((value (funcall fn (first list))))
(if (null value)
(map-and-drop-nils fn (rest list))
(cons value (map-and-drop-nils fn (rest list)))))))
(map-and-drop-nils #'plusp '(0 12 3 4 9 -1)) ==> (T T T T)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote:
> ;; what was discussed in the thread
> (defun map-and-drop-nils (fn list)
MAP-IF ?
Cheers,
-- Nikodemus
To me, the name map-if doesn't imply that the if-not's will be dropped.
Nikodemus Siivola wrote:
> Matthew Danish <·······@andrew.cmu.edu> wrote:
>
>
>>;; what was discussed in the thread
>>(defun map-and-drop-nils (fn list)
>
>
> MAP-IF ?
>
> Cheers,
>
> -- Nikodemus
Lowell <······@cs.ubc.ca> wrote in message news:<············@mughi.cs.ubc.ca>...
> To me, the name map-if doesn't imply that the if-not's will be dropped.
>
> Nikodemus Siivola wrote:
>
> > Matthew Danish <·······@andrew.cmu.edu> wrote:
> >
> >
> >>;; what was discussed in the thread
> >>(defun map-and-drop-nils (fn list)
> >
> >
> > MAP-IF ?
I think the functional programmers (Haskellers and MLers) call it
PARTIAL-MAP, meaning it will only keep the mapped value if it is
"SOME" value instead of "NONE" (that is SML jargon for the Option
type). Haskellers call this type Maybe which is either Just a value or
Nothing. In CL we just stick with generalized booleans, i.e. NIL or
something...
Sorry about the bad explanation. I hope it is clear enough.
--
Dennis Decker Jensen
From: Nils Goesche
Subject: Re: Function names and "filter" function
Date:
Message-ID: <lyd6fqety3.fsf@cartan.de>
Matthew Danish <·······@andrew.cmu.edu> writes:
> (map-and-drop-nils #'plusp '(0 12 3 4 9 -1)) ==> (T T T T)
I maintain that this function is callously misnomed ;-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
> Except that 'filter' already has a widely-used definition in
> programming, and it's not (remove nil (mapcar fn list)).
> (filter #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
> (remove-if-not #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
Exactly- That definition already has the name remove-if-not in lisp,
so I'd think it would be ok to use that name for a different (but
vaguely similar) purpose.
"Conrad Barski" <·····················@yahoo.com> wrote in message
·································@posting.google.com...
> > Except that 'filter' already has a widely-used definition in
> > programming, and it's not (remove nil (mapcar fn list)).
>
> > (filter #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
> > (remove-if-not #'plusp '(0 12 3 4 9 -1)) ==> (12 3 4 9)
>
> Exactly- That definition already has the name remove-if-not in lisp,
> so I'd think it would be ok to use that name for a different (but
> vaguely similar) purpose.
As was already pointed out, filter (ala this thread) and remove-if-not (ala
CL) are not the same thing:
(filter #'(lambda (n) (when (plusp n) (* n 2))) '(0 12 3 4 9 -1))
==> (24 6 8 18)
(remove-if-not #'(lambda (n) (when (plusp n) (* n 2))) '(0 12 3 4 9 -1))
==> (12 3 4 9)
Barry just fell in that trap too.
I think that, plus all the hassle trying to name it, is a good indication
that it has no name and you should just use the crystal clear and easy to
type/read:
(delete nil (mapcar fn list))
collect-result-if might work though.
(defun collect-result-if (pred fn flist &rest olists) ...)
but this does not allow the non-nil assumption. That's because its not good
to assume that. So how about:
(defun collect-result-if-non-nil (fn flist &rest olists) ...)
A long name, but it is not such an obvious desire that it can be expressed
unambiguously in <8 characters!
So what are we trying to gain here? Ease of use? Readability? Too short a
name sacrifices too much of the latter for the former. With auto-complete a
long name is not a problem. Both concerns are satisfied by (delete nil
(mapcar fn list))Concerned about CPU efficiency? Better use that long-named
function and write it carefully. Then again, if it's only ever a single arg
function, what's better than
(loop for elt in list when (funcall fn elt) collect it)
If you share Paul Graham's desire for short names, we can have the best of
both worlds, write the function with the long name for general use and then
use PG's alias macro in your private files.
Hmm, here's another name suggestion: map-and-filter. But what order to put
the parameters? (defun map-and-filter (fn list pred) ..) seems right for
the name but different from other function sigs. It also lets you do:
(defun map-and-filter (fn seq &optional (pred #'identity)) ...)
That seems not a bad idea...maybe I just talked myself in a circle. The
rest is mere implementation detail ;)
In article <····························@posting.google.com>,
Eric Smith <········@yahoo.com> wrote:
>Given the function (filter func list) which
>applies func to each element of list and
>returns a list of the non-nil results, and
>given a desire to name it something other
>than filter, what does everyone think would
>be the best name for this function?
REMOVE-IF-NOT. It's such a good name that it's already used for a function
that does precisely what your FILTER does.
>A more general question is what percentage of
>our programming time should we spend naming
>functions? If we don't spend enough, the names
>might waste our time later, but if we spend too
>much, our time has already been wasted. Where
>is the best compromise between those extremes?
This is part of the "art" of programming. Choosing reasonable names is one
of the factors that affects how readable your code is. If you're writing a
library for public use, it impacts how usable it is.
You should probably spend a little more time on naming the functions and
variables that provide the public API. Internal functions and variables
are less critical, but decent names will make the code more maintainable.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F29A8D5.5040109@nyc.rr.com>
Barry Margolin wrote:
> In article <····························@posting.google.com>,
> Eric Smith <········@yahoo.com> wrote:
>
>>Given the function (filter func list) which
>>applies func to each element of list and
>>returns a list of the non-nil results, and
>>given a desire to name it something other
>>than filter, what does everyone think would
>>be the best name for this function?
>
>
> REMOVE-IF-NOT. It's such a good name that it's already used for a function
> that does precisely what your FILTER does.
>
>
>>A more general question is what percentage of
>>our programming time should we spend naming
>>functions? If we don't spend enough, the names
>>might waste our time later, but if we spend too
>>much, our time has already been wasted. Where
>>is the best compromise between those extremes?
>
>
> This is part of the "art" of programming. Choosing reasonable names is one
> of the factors that affects how readable your code is. If you're writing a
> library for public use, it impacts how usable it is.
Public does not matter. I once took over code from a brilliant coder,
someone not even doing code as his main job. ie, the "brilliant" was
him, not his coding, but that was pretty effective, too.
So it turns out he had these four variables, a, b, c, and d. No sh*t.
They finally got to me, so I worked out a good name for each and started
a global edit/replace, but eyeballing each one. In one case the code did
not make sense after the substitution, so I called the guy over and
asked him what was up right there.
"Oh!", he cried. "I never could find that bug!"
The better names had made manifest a bug so hard to find that a very
bright guy gave up on finding it! (I guess it only came up in rare
circumstances, and the thing was just a browser.)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F285B1B.3000404@nyc.rr.com>
Eric Smith wrote:
> Given the function (filter func list) which
> applies func to each element of list and
> returns a list of the non-nil results, and
> given a desire to name it something other
> than filter, what does everyone think would
> be the best name for this function?
You call SOME to get the first non-nil predicate result, how about
MAPSOME? Don't forget the KEY and TEST options.
I called mine GATHER.
>
> (This is from the recent thread whose subject
> line is "looking for a more elegant solution
> to a simple problem".
>
> A more general question is what percentage of
> our programming time should we spend naming
> functions? If we don't spend enough, the names
> might waste our time later, but if we spend too
> much, our time has already been wasted. Where
> is the best compromise between those extremes?
Forunately we have Tilton's First Law of Programming to guide us:
"Spend more time on your data and function names than on your algorithm."
btw, this: "If we don't spend enough, the names might waste our time
later, but if we spend too much, our time has already been wasted."
needs some debugging. It begs the question of how much is enough.
The answer is simply to take the process seriously. That way you will
slow down and think when choosing a non-obvious name. And you'll go back
and change them all when you think of a better name.
My II.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Eric Smith wrote:
> > Given the function (filter func list) which
> > applies func to each element of list and
> > returns a list of the non-nil results, and
> > given a desire to name it something other
> > than filter, what does everyone think would
> > be the best name for this function?
>
> You call SOME to get the first non-nil predicate result, how about
> MAPSOME? Don't forget the KEY and TEST options.
Ooh, bad name; the MAPx functions can map across multiple lists (god
bless them).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> Ooh, bad name; the MAPx functions can map across multiple lists (god
> bless them).
Maybe it should do that too. We could call
it mapt and make it work exactly like mapcar
except that it would omit the nil results.
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F2972E1.3070107@nyc.rr.com>
Eric Smith wrote:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
>
>
>>Ooh, bad name; the MAPx functions can map across multiple lists (god
>>bless them).
>
>
> Maybe it should do that too. We could call
> it mapt and make it work exactly like mapcar
> except that it would omit the nil results.
I thought of that, but then we lose the TEST and KEY keywords. Which
should it be?
What about EVERYTHING?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F295112.3090905@nyc.rr.com>
Thomas F. Burdick wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Eric Smith wrote:
>>
>>>Given the function (filter func list) which
>>>applies func to each element of list and
>>>returns a list of the non-nil results, and
>>>given a desire to name it something other
>>>than filter, what does everyone think would
>>>be the best name for this function?
>>
>>You call SOME to get the first non-nil predicate result, how about
>>MAPSOME? Don't forget the KEY and TEST options.
>
>
> Ooh, bad name; the MAPx functions can map across multiple lists (god
> bless them).
And we can't support multiple lists without ditching the keyword args.
Hmmmm...
somesuch?
everysome?
somes would be cute. getsome would... uh-oh.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <················@nyc.rr.com>, Kenny Tilton wrote:
>
>
> Thomas F. Burdick wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>>Eric Smith wrote:
>>>
>>>>Given the function (filter func list) which
>>>>applies func to each element of list and
>>>>returns a list of the non-nil results, and
>>>>given a desire to name it something other
>>>>than filter, what does everyone think would
>>>>be the best name for this function?
>>>
>>>You call SOME to get the first non-nil predicate result, how about
>>>MAPSOME? Don't forget the KEY and TEST options.
>>
>>
>> Ooh, bad name; the MAPx functions can map across multiple lists (god
>> bless them).
>
> And we can't support multiple lists without ditching the keyword args.
> Hmmmm...
>
> somesuch?
>
> everysome?
>
> somes would be cute. getsome would... uh-oh.
To me, the name should make it clear that you are collecting the
non-null application results, not the list elements themselves. Also,
because the initial functional argument acts as a predicate, I would
advocate an ...-IF type of name.
Existing operators of that ilk (with the exceptions of FIND-IF and
POSITION-IF) default to traversing the entire sequence/tree, giving us
the universal quantification flavor that a name based on 'SOME' might
lack.
Suppose we say for the sake of illustration that we call having a
predicate returns non-NIL as 'succeeding'; the predicate value is a
'success.' Then we could have SUCCEED-IF be sugar for REMOVE-IF-NOT,
while the operator under discussion would be the clearly related
SUCCESSES-IF.
P. Graham called it FILTER. I argue FILTER (and especially FILTER-IF)
doesn't do a good job of denoting the nature of the detritus to the
casual reader.
I don't like SUCCEED/SUCCESS, since they trespass on the notion of
failure, which connotes something stronger than just returning NIL.
WIN-IF/WINNINGS-IF?
PASS-IF/PASSES-IF?
ACCEPT-IF/ACCEPTANCES-IF?
ADMIT-IF/ADMISSIONS-IF? or ADMITTANCES-IF?
ALLOW-IF/ALLOWANCES-IF?
etc.
Andrew
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F29A6D8.1020504@nyc.rr.com>
Andrew Philpot wrote:
> In article <················@nyc.rr.com>, Kenny Tilton wrote:
>
>>
>>Thomas F. Burdick wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>
>>>>Eric Smith wrote:
>>>>
>>>>
>>>>>Given the function (filter func list) which
>>>>>applies func to each element of list and
>>>>>returns a list of the non-nil results, and
>>>>>given a desire to name it something other
>>>>>than filter, what does everyone think would
>>>>>be the best name for this function?
>>>>
>>>>You call SOME to get the first non-nil predicate result, how about
>>>>MAPSOME? Don't forget the KEY and TEST options.
>>>
>>>
>>>Ooh, bad name; the MAPx functions can map across multiple lists (god
>>>bless them).
>>
>>And we can't support multiple lists without ditching the keyword args.
>>Hmmmm...
>>
>>somesuch?
>>
>>everysome?
>>
>>somes would be cute. getsome would... uh-oh.
>
>
> To me, the name should make it clear that you are collecting the
> non-null application results, not the list elements themselves. Also,
> because the initial functional argument acts as a predicate, I would
> advocate an ...-IF type of name.
>
> Existing operators of that ilk (with the exceptions of FIND-IF and
> POSITION-IF) default to traversing the entire sequence/tree, giving us
> the universal quantification flavor that a name based on 'SOME' might
> lack.
>
> Suppose we say for the sake of illustration that we call having a
> predicate returns non-NIL as 'succeeding'; the predicate value is a
> 'success.' Then we could have SUCCEED-IF be sugar for REMOVE-IF-NOT,
You just gave me an idea: KEEP-SOME?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Andrew Philpot wrote:
> >>somes would be cute. getsome would... uh-oh.
would ... be depressing when it returned NIL? :)
> > To me, the name should make it clear that you are collecting the
> > non-null application results, not the list elements themselves. Also,
> > because the initial functional argument acts as a predicate, I would
> > advocate an ...-IF type of name. Existing operators of that ilk
> > (with the exceptions of FIND-IF and
> > POSITION-IF) default to traversing the entire sequence/tree, giving us
> > the universal quantification flavor that a name based on 'SOME' might
> > lack.
> > Suppose we say for the sake of illustration that we call having a
> > predicate returns non-NIL as 'succeeding'; the predicate value is a
> > 'success.' Then we could have SUCCEED-IF be sugar for REMOVE-IF-NOT,
>
> You just gave me an idea: KEEP-SOME?
That kind of works. The KEEP part is okay, but the SOME implies the
correct association, and would show up in APROPOS. I just found my
implementation: apparently I called it COLLECT-IF. Ug. No wonder I
never use it (it's completely unrelated to my WITH-COLLECTORS/COLLECT
utilities).
Of course, this only works with semipredicates; maybe a better way
would be to use MAPCAN where appropriate, or extend REMOVE-IF-NOT and
friends with an :IDENTITY option:
(remove-if-not* #'plusp '(0 1 -12 24 -6)
:key #'1+ :identity #'plusp)
=> (NIL T T)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Andrew Philpot <·······@isi.edu> writes:
>
> I don't like SUCCEED/SUCCESS, since they trespass on the notion of
> failure, which connotes something stronger than just returning NIL.
>
> WIN-IF/WINNINGS-IF?
> PASS-IF/PASSES-IF?
> ACCEPT-IF/ACCEPTANCES-IF?
> ADMIT-IF/ADMISSIONS-IF? or ADMITTANCES-IF?
> ALLOW-IF/ALLOWANCES-IF?
> etc.
>
> Andrew
COLLECT-IF
(Assuming this passes our collective asthetic judgement).
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>, Thomas A. Russ wrote:
> Andrew Philpot <·······@isi.edu> writes:
>>
>> I don't like SUCCEED/SUCCESS, since they trespass on the notion of
>> failure, which connotes something stronger than just returning NIL.
>>
>> WIN-IF/WINNINGS-IF?
>> PASS-IF/PASSES-IF?
>> ACCEPT-IF/ACCEPTANCES-IF?
>> ADMIT-IF/ADMISSIONS-IF? or ADMITTANCES-IF?
>> ALLOW-IF/ALLOWANCES-IF?
>> etc.
>>
>> Andrew
>
> COLLECT-IF
>
> (Assuming this passes our collective asthetic judgement).
>
Grrrr. I'm probably hyper-persnickety about this, but to me,
COLLECT-IF would be ambiguous, worse even than FILTER-IF. In the
context of the general idea of LOOP's COLLECT keyword, a reader could
ask herself:
Does (COLLECT-IF #'oddp '(1 2 3 4 5)) mean
CL-USER(49): (loop for j from 1 to 5 when (oddp j) collect j)
(1 3 5)
or
CL-USER(50): (loop for j from 1 to 5 when (oddp j) collect it)
(T T T)
I have an entire KEEP family of sequence functions, all equivalent to
the corresponding REMOVE with :TEST complemented. I never get
confused about what they mean, and sometimes they read better than
REMOVE-IF-NOT or REMOVE/COMPLEMENT, so I use them from time to time.
In contrast, I think I would code around COLLECT-IF because I would
not feel as sure about its immediate readability.
Anyone know what this would be (or would be called) in APL?
Andrew
"Eric Smith" <········@yahoo.com> wrote in message
·································@posting.google.com...
> Given the function (filter func list) which
[snip]
Personally, I am not convinced it is a common enough need that doing
something explicit is worse than trying to find a meaningful general purpose
name.
(delete nil (mapcar func list)) is to me the minimal expression of what you
want.
> A more general question is what percentage of
> our programming time should we spend naming
> functions? If we don't spend enough, the names
> might waste our time later, but if we spend too
> much, our time has already been wasted. Where
> is the best compromise between those extremes?
I am a firm believer in the importance of finding the right name. Often
that struggle helps solidify your abstractions, makes you realize you don't
really want what you think or it is something else you want to achieve. To
me, if you can not find the right name it indicates a possible design
problem. The above is an example of that, I think the fact that (assuming
"I can't think of one" means "there is none" ;) there is no good name for
what you want above indicates it is not appropriate for its own function.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F2858D9.8040808@nyc.rr.com>
Coby Beck wrote:
> "Eric Smith" <········@yahoo.com> wrote in message
> ·································@posting.google.com...
>
>>Given the function (filter func list) which
>
> [snip]
>
> Personally, I am not convinced it is a common enough need that doing
> something explicit is worse than trying to find a meaningful general purpose
> name.
>
> (delete nil (mapcar func list)) is to me the minimal expression of what you
> want.
There you go again. <rofl>
great, you create all that structure just to throw it away in the next
instruction!
I know, we agree. <g>
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Eric Smith wrote:
> Given the function (filter func list) which
> applies func to each element of list and
> returns a list of the non-nil results, and
> given a desire to name it something other
> than filter, what does everyone think would
> be the best name for this function?
GREP
Eric Smith writes:
> Given the function (filter func list) which
> applies func to each element of list and
> returns a list of the non-nil results, and
> given a desire to name it something other
> than filter, what does everyone think would
> be the best name for this function?
filter and mapcar-if are unsuitable to name something like
(lambda (function &rest lists)
(apply #'mapcan
(lambda (arg) (let ((value (funcall function arg)))
(if value
(list value)
'())))
lists))
How about mapclan ?
(defun mapclan (function &rest lists)
(let ((result '()))
(dolist (args (zip lists) (nreverse result))
(let ((value (apply function args)))
(when value (push value result))))))
--
"Hurry if you still want to see something. Everything is vanishing."
-- Paul C�zanne (1839-1906)
········@yahoo.com (Eric Smith) wrote in message news:<····························@posting.google.com>...
> Given the function (filter func list) which
> applies func to each element of list and
> returns a list of the non-nil results, and
> given a desire to name it something other
> than filter, what does everyone think would
> be the best name for this function?
I checked Paul Graham, Peter Norvig,
SICP (Harold Abelson et al.) and the SRFI-1 from
the schemers (http://srfi.schemers.org)
It seems that Paul Graham may be wrong here.
Peter Norvig, Harold Abelson et al. and the SRFI-1
all give the filter function the same functionality as
remove-if-not in CL (which by the way is deprecated,
you should use the complement function with remove-if instead).
Peter Norvig uses his filter function on his pipes impl. though.
Note: Ocaml, SML, Python, etc. seems to agree. In Ruby
filter was renamed to find-all-if which is the same name that
Peter Norvig used for it in PAIP.
The schemers call their SRFI-1 function filter-map, which
after all indicates the combined functionality
very well -- map and filter in that order.An alternative
might be map-partial (SML jargon).
I can remember filter-map...
> A more general question is what percentage of
> our programming time should we spend naming
> functions?
Very much. Language affects our thinking hence
not only what we do and the results but also
the quality there of. You cannot spend too
much time considering names. Changing names
is a sign of change in design about to come up.
--
Dennis Decker Jensen
·············@hotmail.com (Dennis Decker Jensen) writes:
> remove-if-not in CL (which by the way is deprecated, you should use
> the complement function with remove-if instead).
Actually, I think the deprecation of remove-if-not has itself been
(informally) deprecated. For example here's what Kent Pitman had to
say about it couple years ago in Message-ID:
<···············@shell01.TheWorld.com>. Note, however, that (according
to Kent) the deprecation of the :test-not arguments should still be
observed:
kent> I think it's generally accepted in the community that we made a
kent> mistake deprecating those.
kent> You should use :test (complement test) rather than :test-not
kent> test. But for the -if-not functions, just use them and ignore
kent> the deprecation.
kent> Deprecated functions are still required to be supported
kent> correctly in all conforming implementations.
kent> For information on the meaning of deprecation, see CLHS (I think
kent> it's in chapter 1 somewhere).
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
·············@hotmail.com (Dennis Decker Jensen) writes:
> remove-if-not in CL (which by the way is deprecated,
> you should use the complement function with remove-if instead).
Over my dead body. :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Kenny Tilton
Subject: Re: Function names and "filter" function
Date:
Message-ID: <3F2B9476.6070807@nyc.rr.com>
Christophe Rhodes wrote:
> ·············@hotmail.com (Dennis Decker Jensen) writes:
>
>
>>remove-if-not in CL (which by the way is deprecated,
>>you should use the complement function with remove-if instead).
>
>
> Over my dead body. :-)
would that be (complement christophe)?
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
begin of a quotation from the text written by:
Christophe Rhodes <·····@cam.ac.uk>:
> ·············@hotmail.com (Dennis Decker Jensen) writes:
>
> > remove-if-not in CL (which by the way is deprecated,
> > you should use the complement function with remove-if instead).
>
> Over my dead body. :-)
Wouldn't the GC allready have taken care of that before the function kicked in
...;-))
cor
--
The Inca's used strings to communicate 5000 yrs ago, computers still do.
Good things hardly ever change
(setq reply-to (concatenate 'string "Cor Gest ""<cor"'(··@)"clsnet.nl>"))