std.algorithm - notes

[Jari-Matti Mäkelä]

On Thu, 6 Mar 2008, Jarrod wrote:

> On Wed, 05 Mar 2008 11:35:47 -0500, bearophile wrote:
>
>> I think that a list comp can avoid you
>> to create map/filter/xmap/xfilter, and you can improve code readability,
>> etc.
>
> I disagree. D is a straightforward language. Adding python list
> generation adds a big 'special case' scenario. Wrapping a for loop inside
> square brackets? Hmm I don't think that's better than using map/filter.
> Look at it from a non-python perspective: Every 'for' iteration does not
> generate a return value, so how can each cycle of a for loop logically
> create a list element?
> At least with map/filter you can see the cascading pattern straight away.
> By looking at the documentation you know what they return and by being
> seen as functions rather than built in methods, any programmer can see
> how they will flow (simply take arguments in the brackets, spit out a
> return value).

One advantage of list/array comprehensions is that the language can more 
easily optimize the "query" (I guess LINQ like stuff is becoming more 
common these days). With subsequent function calls the compiler would need 
fairly advanced syntax tree manipulation strategies that may be hard to 
reason about unless the functions are pure. I won't say anything about the 
declarative nature since the syntax, if fitted to D, would not probably 
be very cute anyway.

> With that said, more ordinary list operations would indeed be a blessing,
> such as:
>> a,b = 1,2;
>> a,b = b,a;
>> return (a,b);

List operations? These look like first class tuples to me. Let's hope they 
are still on the todo list.

>
> Just my thoughts.
>