"
According to the language standard, the -IF-NOT variants are deprecated. However, that deprecation is generally considered to have itself been ill-advised. If the standard is ever revised, it's more likely the deprecation will be removed than the -IF-NOT functions. For one thing, the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. Despite its negative-sounding name, REMOVE-IF-NOT is actually the positive variant--it returns the elements that do satisfy the predicate.
"
Is there a general consensus (preference, understanding, whatever) on whether -if-not is preferred or -if, but having the method that you're using wrapped in (complement #'function-test)?
> "
> According to the language standard, the -IF-NOT variants are deprecated. However, that deprecation is generally considered to have itself been ill-advised. If the standard is ever revised, it's more likely the deprecation will be removed than the -IF-NOT functions. For one thing, the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. Despite its negative-sounding name, REMOVE-IF-NOT is actually the positive variant--it returns the elements that do satisfy the predicate.
> "
> Is there a general consensus (preference, understanding, whatever) on whether -if-not is preferred or -if, but having the method that you're using wrapped in (complement #'function-test)?
REMOVE-IF-NOT is not particularly hard to understand, and its semantics are not problematic in any way. It's also fewer characters to type than the alternatives, so it's definitely fine to use it.
COMPLEMENT is funky, IMO. But hey, if prefer that, go ahead...
> > According to the language standard, the -IF-NOT variants are deprecated. However, that deprecation is generally considered to have itself been ill-advised. If the standard is ever revised, it's more likely the deprecation will be removed than the -IF-NOT functions. For one thing, the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. Despite its negative-sounding name, REMOVE-IF-NOT is actually the positive variant--it returns the elements that do satisfy the predicate.
> > "
> > Is there a general consensus (preference, understanding, whatever) on whether -if-not is preferred or -if, but having the method that you're using wrapped in (complement #'function-test)?
> REMOVE-IF-NOT is not particularly hard to understand, and its semantics
> are not problematic in any way. It's also fewer characters to type than
> the alternatives, so it's definitely fine to use it.
> COMPLEMENT is funky, IMO. But hey, if prefer that, go ahead...
> > > According to the language standard, the -IF-NOT variants are deprecated. > > > However, that deprecation is generally considered to have itself been > > > ill-advised. If the standard is ever revised, it's more likely the > > > deprecation will be removed than the -IF-NOT functions. For one thing, > > > the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. > > > Despite its negative-sounding name, REMOVE-IF-NOT is actually the > > > positive variant--it returns the elements that do satisfy the predicate.
> > > "
> > > Is there a general consensus (preference, understanding, whatever) on > > > whether -if-not is preferred or -if, but having the method that you're > > > using wrapped in (complement #'function-test)?
> > REMOVE-IF-NOT is not particularly hard to understand, and its semantics
> > are not problematic in any way. It's also fewer characters to type than
> > the alternatives, so it's definitely fine to use it.
> > COMPLEMENT is funky, IMO. But hey, if prefer that, go ahead...
> > > > According to the language standard, the -IF-NOT variants are > > > > deprecated. > > > > However, that deprecation is generally considered to have itself been > > > > ill-advised. If the standard is ever revised, it's more likely the > > > > deprecation will be removed than the -IF-NOT functions. For one thing, > > > > the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. > > > > Despite its negative-sounding name, REMOVE-IF-NOT is actually the > > > > positive variant--it returns the elements that do satisfy the > > > > predicate.
> > > > "
> > > > Is there a general consensus (preference, understanding, whatever) on > > > > whether -if-not is preferred or -if, but having the method that you're > > > > using wrapped in (complement #'function-test)?
> > > REMOVE-IF-NOT is not particularly hard to understand, and its semantics
> > > are not problematic in any way. It's also fewer characters to type than
> > > the alternatives, so it's definitely fine to use it.
> > > COMPLEMENT is funky, IMO. But hey, if prefer that, go ahead...
In article <dd3053ee-17fa-42cc-beac-590d45349768@googlegroups.com>,
Elias Mårtenson <loke...@gmail.com> wrote:
> On Wednesday, 19 September 2012 12:29:20 UTC+8, Teemu Likonen wrote:
> > RG [2012-09-18 11:26:26 -0700] wrote:
> > > Personally, I think the right name for REMOVE-IF-NOT is FILTER.
> > Personally I wouldn't know if FILTER means REMOVE-IF or REMOVE-IF-NOT.
> If we're talking about a hypothetical rename that will never happen, here's > another suggestion:
> KEEP-IF
I like FILTER not because its meaning is self-evident but because it's a universal convention in the functional programming world that filter means remove-if-not. But KEEP-IF is good to.
RG <rNOSPA...@flownet.com> writes:
> I like FILTER not because its meaning is self-evident but because it's a > universal convention in the functional programming world that filter > means remove-if-not. But KEEP-IF is good to.
Then an even better word than FILTER would be: DEMETER-IN-THE-FIELDS
The remove-if function produces a list whose contents are those
of <list> but with those elements removed which satisfy <predi-
cate-function>. Those elements which are not removed appear in
the same order. The result list may share substructure with the
input list, and may even be the same list object if no items are
removed.
The optional <key-function> specifies how each element from the
<list> is transformed to an argument to <predicate-function>. If
this argument is omitted or specified as nil, then the predicate
function is applied to the elements directly, a behavior which
is identical to <key-function> being (fun identity).
The keep-if function is exactly like remove-if, except the sense
of the predicate is inverted. The function keep-if retains those
items which remove-if will delete, and removes those that
remove-if will preserve.
The remove-if* and keep-if* are like remove-if and keep-if, but
produce lazy lists.
Examples:
;; remove any element numerically equal to 3.
(remove-if (op = 3) '(1 2 3 4 3.0 5)) -> (1 2 4 5)
;; remove those pairs whose first element begins with "abc"
[remove-if (op equal [@1 0..3] "abc")
'(("abcd" 4) ("defg" 5))
car]
-> (("defg 5))
;; equivalent, without key function
(remove-if (op equal [(car @1) 0..3] "abc")
'(("abcd" 4) ("defg" 5)))
-> (("defg 5))
> In article <dd3053ee-17fa-42cc-beac-590d45349768@googlegroups.com>,
> Elias Mårtenson <loke...@gmail.com> wrote:
>> On Wednesday, 19 September 2012 12:29:20 UTC+8, Teemu Likonen wrote:
>> > RG [2012-09-18 11:26:26 -0700] wrote:
>> > > Personally, I think the right name for REMOVE-IF-NOT is FILTER.
>> > Personally I wouldn't know if FILTER means REMOVE-IF or REMOVE-IF-NOT.
>> If we're talking about a hypothetical rename that will never happen, here's >> another suggestion:
>> KEEP-IF
> I like FILTER not because its meaning is self-evident but because it's a > universal convention in the functional programming world that filter > means remove-if-not. But KEEP-IF is good to.
Haha, check this.
In the GNU Make language (which I hardly need point out is more popular and
widely used than any functional language) you have these:
$(filter pattern...,text)
Returns all whitespace-separated words in text that do match any
of the pattern words, removing any words that do not match. The
patterns are written using ‘%’, just like the patterns used in
the patsubst function above.
[ snip examples ]
$(filter-out pattern...,text)
Returns all whitespace-separated words in text that do not match
any of the pattern words, removing the words that do match one or
more. This is the exact opposite of the filter function.
> > "
> > According to the language standard, the -IF-NOT variants are deprecated. However, that deprecation is generally considered to have itself been ill-advised. If the standard is ever revised, it's more likely the deprecation will be removed than the -IF-NOT functions. For one thing, the REMOVE-IF-NOT variant is probably used more often than REMOVE-IF. Despite its negative-sounding name, REMOVE-IF-NOT is actually the positive variant--it returns the elements that do satisfy the predicate.
> > "
> > Is there a general consensus (preference, understanding, whatever) on whether -if-not is preferred or -if, but having the method that you're using wrapped in (complement #'function-test)?
> REMOVE-IF-NOT is not particularly hard to understand, and its semantics are not problematic in any way. It's also fewer characters to type than the alternatives, so it's definitely fine to use it.
> COMPLEMENT is funky, IMO. But hey, if prefer that, go ahead...
> Pascal
Instead of using DARPA CL, let's use a Lispy language.
RG wrote:
> In article <dd3053ee-17fa-42cc-beac-590d45349768@googlegroups.com>,
> Elias Mårtenson <loke...@gmail.com> wrote:
> > On Wednesday, 19 September 2012 12:29:20 UTC+8, Teemu Likonen wrote:
> > > RG [2012-09-18 11:26:26 -0700] wrote:
> > > > Personally, I think the right name for REMOVE-IF-NOT is FILTER.
> > > Personally I wouldn't know if FILTER means REMOVE-IF or REMOVE-IF-NOT.
> > If we're talking about a hypothetical rename that will never happen, here's > > another suggestion:
> > KEEP-IF
> I like FILTER not because its meaning is self-evident but because it's a > universal convention in the functional programming world that filter > means remove-if-not. But KEEP-IF is good to.
> Or we could go with DONT-REMOVE-IF-NOT-NULL.
Excellent suggestion, much more in keeping with the
DARPA CL philosophy.
"Do you not never read no newspapers?" (Midnight Manhunt)
Pascal J. Bourguignon wrote:
> RG <rNOSPA...@flownet.com> writes:
> > I like FILTER not because its meaning is self-evident but because it's a > > universal convention in the functional programming world that filter > > means remove-if-not. But KEEP-IF is good to.
> Then an even better word than FILTER would be: DEMETER-IN-THE-FIELDS
Another example of the "thinking" that has made
DARPA CL the ugliest, clunkiest language that
the world has ever known.
