February 14, 2013
On 2/14/2013 12:12 AM, Jacob Carlborg wrote:
> On 2013-02-13 21:19, Walter Bright wrote:
>
>> The any in std.algorithm is defined:
>>
>> --------------
>> bool any(alias pred, Range)(Range range);
>>
>> Returns true if and only if a value v satisfying the predicate pred can
>> be found in the forward range range. Performs Ο(r.length) evaluations of
>> pred.
>> --------------
>>
>> I see that as very different from !empty.
>
> But if you use a predicate that always returns true that would be basically the
> same. At least for arrays.
>
> int[] a = [];
> assert(a.any!(e => true) == false);
>
> int[] b = [3, 4, 5];
> assert(b.any!(e => true) == true);

I don't understand why one would go around the horn to just check for !empty.

February 14, 2013
On 2/14/2013 12:32 AM, bearophile wrote:
> Walter Bright:
>
>> The trivial ones should not be added to Phobos,
>
> The situation is not that simple.

The trouble is, where do you stop adding trivia? How about this one:

   T addThree(T t) { return t + 3; }

?

A good interface design has the *minimum* number of functions out of which anything else can be built. Functions that are recombinations of other functions in the same interface do not belong in that interface.

It's tempting to create kitchen sink abstractions, but they really are a bad idea.

February 14, 2013
On 2013-02-14 10:46, Walter Bright wrote:

> I don't understand why one would go around the horn to just check for
> !empty.

I've tried to explain, it shows what the intention is.

Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any".

It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.

-- 
/Jacob Carlborg
February 14, 2013
On Tue, 12 Feb 2013 12:38:53 -0000, Jacob Carlborg <doob@me.com> wrote:
> * std.getopt - Doesn't support the following:
>    * Required arguments
>    * Restricting the values of a given argument
>    * No way to automatically create a help/usage list out of the arguments
>    * Handling positional arguments
>    * No support for commands/action. That is "git commit", "commit" would be the command/action
>    * Handle multiple command lines
>    * Validation of the arguments

Just a minor point from me.  I reckon the functionality you want can and should be built on top of std.getopt.

As others have said you could either do this first and get it submitted to phobos, and then work on the other issues and getting Orbit itself in there.. or you can build this functionality into a module within Orbit and then work on getting that extracted as a separate module in phobos.

The former delays ppl being able to use Orbit, the latter means more work down the line to refactor Orbit - tho hopefully this will just be an import declaration change, tho it may also include a slight API change if ppl are unhappy with the existing one.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
February 14, 2013
On 2013-02-14 11:58:12 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-02-14 10:46, Walter Bright wrote:
> 
>> I don't understand why one would go around the horn to just check for
>> !empty.
> 
> I've tried to explain, it shows what the intention is.
> 
> Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any".
> 
> It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.

I'd agree it's more readable, but it does not do what I expect when I read it: to me 'any' sounds like an accessor that would take an item at an unspecified position in a container (likely the less costly to get); std.container defines 'removeAny' following that line. The correct name would be 'hasAny'.

In this case I think it'd be much better if the language just translated "if (str)" to something equivalent to "if (!str.empty)".

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

February 14, 2013
On 2/14/13 6:58 AM, Jacob Carlborg wrote:
> On 2013-02-14 10:46, Walter Bright wrote:
>
>> I don't understand why one would go around the horn to just check for
>> !empty.
>
> I've tried to explain, it shows what the intention is.
>
> Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty"
> I like to use "str.any".
>
> It's not a big deal but I would need to change quite a lot of code if
> "str.any" isn't allowed.

I understand. Adding functions such as the negation of empty becomes a judgment call.

Phobos does have quite a few simple functions that could be easily achieved through expression composition (e.g. trim) or statement composition (e.g. enforce). So again it's all a matter of judgment.

Walter and I don't consider the negation of empty as useful enough to receive a name.

There's been a talk (discussed on reddit) on Ruby by a prominent member of that community. At a point the talk addressed the awesomeness of "unless" (the negation of "if") - the presence of that near-useless device was seen as a human touch in a world of cold logic. I found the argument rather weak, unless we consider creating clutter and wasting means part of the human touch.

Besides, as often happens with such constructs, there are pitfalls and subsequent dos and donts about "unless" that more than undo whatever utility and expressiveness it may have. The first two hits for https://www.google.com/search?q=ruby%20unless describe "unless, the abused ruby conditional" and "making sense of ruby's unless". Turns out "unless" should not be used with "else" or at the beginning of a statement.

Perl also has "unless", and after years of experience the Perl Best Practices guide http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf curtly says: "Don’t use unless or until at all." If Perl shuns a keyword, that's bound to say something.

D has "any" (previously an overload of "canFind") as an algorithm that finds whether at least one element of a range satisfies a condition, otherwise writable as "!r.find!(a => condition).empty". The convenience/mechanics/generality of the construct was enough justification to add the algorithm. To claim that D already has the negation of empty because one can write "r.any(a => true)" is, in my opinion, an ill-posed argument.


Andrei
February 14, 2013
On Thu, 14 Feb 2013 06:58:12 -0500, Jacob Carlborg <doob@me.com> wrote:

> On 2013-02-14 10:46, Walter Bright wrote:
>
>> I don't understand why one would go around the horn to just check for
>> !empty.
>
> I've tried to explain, it shows what the intention is.
>
> Instead of "str.length == 0" I use "str.empty". Instead of "!str.empty" I like to use "str.any".
>
> It's not a big deal but I would need to change quite a lot of code if "str.any" isn't allowed.

Would this work?

bool any(R)(R r) if(isInputRange!R) { return !r.empty;}

-Steve
February 14, 2013
On Thu, 14 Feb 2013 09:28:25 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> bool any(R)(R r) if(isInputRange!R) { return !r.empty;}

BTW, I noticed 'any' is not listed in the std.algorithm documentation at the top, even though it is in the docs.  Is that a bug with DDoc, or just bad maintenance?

-Steve
February 14, 2013
On 2013-02-14 13:42, Andrei Alexandrescu wrote:

> I understand. Adding functions such as the negation of empty becomes a
> judgment call.
>
> Phobos does have quite a few simple functions that could be easily
> achieved through expression composition (e.g. trim) or statement
> composition (e.g. enforce). So again it's all a matter of judgment.
>
> Walter and I don't consider the negation of empty as useful enough to
> receive a name.

Since you mention Ruby below I can say that D/Phobos could have some more of these convenience methods. Especially if we would like to consider D usable as a scripting language.

> There's been a talk (discussed on reddit) on Ruby by a prominent member
> of that community. At a point the talk addressed the awesomeness of
> "unless" (the negation of "if") - the presence of that near-useless
> device was seen as a human touch in a world of cold logic. I found the
> argument rather weak, unless we consider creating clutter and wasting
> means part of the human touch.
>
> Besides, as often happens with such constructs, there are pitfalls and
> subsequent dos and donts about "unless" that more than undo whatever
> utility and expressiveness it may have. The first two hits for
> https://www.google.com/search?q=ruby%20unless describe "unless, the
> abused ruby conditional" and "making sense of ruby's unless". Turns out
> "unless" should not be used with "else" or at the beginning of a statement.
>
> Perl also has "unless", and after years of experience the Perl Best
> Practices guide
> http://refcards.com/docs/vromansj/perl-best-practices/refguide.pdf
> curtly says: "Don’t use unless or until at all." If Perl shuns a
> keyword, that's bound to say something.

"unless" is kind of a useless keyword. I can tell you that I have used "any" a lot more than I have used "unless".

> D has "any" (previously an overload of "canFind") as an algorithm that
> finds whether at least one element of a range satisfies a condition,
> otherwise writable as "!r.find!(a => condition).empty". The
> convenience/mechanics/generality of the construct was enough
> justification to add the algorithm. To claim that D already has the
> negation of empty because one can write "r.any(a => true)" is, in my
> opinion, an ill-posed argument.

I just thought that we could add a default predicate to the "any" function.

-- 
/Jacob Carlborg
February 14, 2013
On 2013-02-14 15:28, Steven Schveighoffer wrote:

> Would this work?
>
> bool any(R)(R r) if(isInputRange!R) { return !r.empty;}

Yes, I already have something similar. Actually I have this:

@property bool any (T) (T value) if (__traits(compiles, { bool a = value.empty; }))
{
    return !value.empty;
}

-- 
/Jacob Carlborg