www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: First experience with std.algorithm: I had to resort to writing a

reply bearophile <bearophileHUGS lycos.com> writes:
Bernard Helyer:

 bool contains(T)(const(T)[] l, T a)
 {
       foreach(e; l) {
           if (a == e) {
              return true;
           }
       }
       return false;
 }



See also:
http://d.puremagic.com/issues/show_bug.cgi?id=3923

Bye,
bearophile
Jun 08 2010
next sibling parent Alex Makhotin <alex bitprox.com> writes:
bearophile wrote:

  
 See also:
 http://d.puremagic.com/issues/show_bug.cgi?id=3923
 




 Such functions must be simple enough for normal people to use. If you need more
 than 10 minutes to understand how to use something as simple as a "find", then
 the library API is badly designed. It's not a limit of my brain, it's a problem
 in the library design.



Agree.
And by the way naming scheme also brings a lot of confusion, to say the 
least...


-- 
Alex Makhotin,
the founder of BITPROX,
http://bitprox.com
Jun 08 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/08/2010 06:59 AM, bearophile wrote:

 Bernard Helyer:

 bool contains(T)(const(T)[] l, T a)
 {
        foreach(e; l) {
            if (a == e) {
               return true;
            }
        }
        return false;
 }



 See also:
 http://d.puremagic.com/issues/show_bug.cgi?id=3923



That issue stems from the fact that find is quite flexible. I agree it 
has lost modularity in the process. I'll work on restoring its modularity.

Andrei
Jun 08 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Andrei Alexandrescu wrote:


 On 06/08/2010 06:59 AM, bearophile wrote:

 Bernard Helyer:

 bool contains(T)(const(T)[] l, T a)
 {
        foreach(e; l) {
            if (a == e) {
               return true;
            }
        }
        return false;
 }



 See also:
 http://d.puremagic.com/issues/show_bug.cgi?id=3923



 That issue stems from the fact that find is quite flexible. I agree it
 has lost modularity in the process. I'll work on restoring its modularity.
 
 Andrei



The biggest issue is the documentation rather than the function, I think. If 
find() can be broken up, that could help, but the main issue is what the 
documentation looks like. It's just too complicated - especially the 
function signature. Pretty much the only sane way to figure the 
std.algorithm functions out is to focus on the examples (which while good 
are still fairly sparse). As it stands, I expect the documentation to scare 
away potential users of std.algorithm. It looks far scarier than it actually 
is. We need to find a way or ways to make the documentation simple like the 
functions are simple to use (since, for the most part they're pretty easy to 
use in spite of their nasty signatures).

As for a contains() function, I would argue that it would be nice to add one 
regardless of the state of find(). Not only would it would make its usage 
clearer in the use case where you're checking whether a range contains a 
value, but it could almost certainly be better optimized for such a use case 
- if nothing else because it wouldn't have to construct a range, just return 
a bool.

- Jonathan M Davis
Jun 08 2010
parent reply KennyTM~ <kennytm gmail.com> writes:
On Jun 9, 10 03:19, Jonathan M Davis wrote:

 Andrei Alexandrescu wrote:


 On 06/08/2010 06:59 AM, bearophile wrote:

 Bernard Helyer:

 bool contains(T)(const(T)[] l, T a)
 {
         foreach(e; l) {
             if (a == e) {
                return true;
             }
         }
         return false;
 }



 See also:
 http://d.puremagic.com/issues/show_bug.cgi?id=3923



 That issue stems from the fact that find is quite flexible. I agree it
 has lost modularity in the process. I'll work on restoring its modularity.

 Andrei



 The biggest issue is the documentation rather than the function, I think. If
 find() can be broken up, that could help, but the main issue is what the
 documentation looks like. It's just too complicated - especially the
 function signature. Pretty much the only sane way to figure the
 std.algorithm functions out is to focus on the examples (which while good
 are still fairly sparse). As it stands, I expect the documentation to scare
 away potential users of std.algorithm. It looks far scarier than it actually
 is. We need to find a way or ways to make the documentation simple like the
 functions are simple to use (since, for the most part they're pretty easy to
 use in spite of their nasty signatures).



I agree. Especially the return type of many templated methods are so 
complicated that it just adds close to zero information, for example:

   Take!(Sequence!("a.field[0] + n * 
a.field[1]",Tuple!(CommonType!(B,E),uint))) iota(B, E)(B begin, E end);

A better representation is

   auto iota(B, E)(B begin, E end);

Granted, this means some information is lost when reading the signature, 
but no one is going to actually use the Take!(Sequence!whatever)) type 
directly, why bother.

(There's no need to modify ddoc, just add a Javascript on the page is 
enough.)

Another thing is the documentation feels too "crowded", in particular 
that crazy "navigation bar" on the top is a joke. Why can't it laid out 
vertically?

There should be sections within a module to divide relevant functions 
into groups, e.g.

   1. Capability checking

        template isInputRange(R)
        template isOutputRange(R,E)
        ...

   2. Information of range

        size_t walkLength(Range)(Range range, size_t upTo = size_t.max);

   3. Modifying ranges

        auto retro(R)(R input);
        auto stride(R)(R input, size_t n);
        ...

   4. Constructing ranges

        auto recurrence(alias fun, State...)(State initial);
        auto iota(B, E)(B begin, E end);
        ...
Jun 08 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:hume1m$310o$1 digitalmars.com...

   Take!(Sequence!("a.field[0] + n * 
 a.field[1]",Tuple!(CommonType!(B,E),uint))) iota(B, E)(B begin, E end);

 A better representation is

   auto iota(B, E)(B begin, E end);

 Granted, this means some information is lost when reading the signature, 
 but no one is going to actually use the Take!(Sequence!whatever)) type 
 directly, why bother.



Yea, definitely agree. But, of course, there should also be an explanation 
of what type the caller can expect it to return, since auto is dependant on 
implementation and, by itself, doesn't tell the person reading the docs 
anything. Or maybe something like:

{simple description here} iota(B, E)(B begin, E end);

Example:
{element type of range T} getFirstElement(T)(T range);

Or:
{elementTypeOfRange} getFirstElement(T)(T range);
    {elementTypeOfRange}: If needed, a more complete explanation goes here.

I'm doing some things like that for the documentation for Goldie (The 
documentation's still incomplete and only in trunk though. But I'm working 
on it...when I have time...)


 (There's no need to modify ddoc, just add a Javascript on the page is 
 enough.)



Ugh, oh dear God, no!
Jun 08 2010
parent KennyTM~ <kennytm gmail.com> writes:
On Jun 9, 10 06:44, Nick Sabalausky wrote:

 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hume1m$310o$1 digitalmars.com...

 (There's no need to modify ddoc, just add a Javascript on the page is
 enough.)



 Ugh, oh dear God, no!



Hehe. Since DDoc is bound to the spec is D2 is feature-frozen, using 
Javascript can be used as a workaround if DDoc cannot be changed, just 
like how the navigation bar is generated.
Jun 08 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/08/2010 04:51 PM, KennyTM~ wrote:

 A better representation is

 auto iota(B, E)(B begin, E end);



FWIW that's how I first defined it. At that time ddoc had a bug that 
made all auto functions invisible. I think that has been fixed since.

Andrei
Jun 08 2010
parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 On 06/08/2010 04:51 PM, KennyTM~ wrote:

 A better representation is

 auto iota(B, E)(B begin, E end);



 FWIW that's how I first defined it. At that time ddoc had a bug that 
 made all auto functions invisible. I think that has been fixed since.
 
 Andrei
Jun 08 2010