Any chance to call Tango as Extended Standard Library

[Michel Fortin]

On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> dsimcha wrote:
>> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>>> dsimcha wrote:
>>>> One point of clarification:  opApply isn't going to be deprecated 
>>>> anytime soon, is
>>>> it?  It seems like ranges still have a bunch of rough edges, and 
>>>> although I like
>>>> the idea in principle, I'm only willing to convert to ranges if I can define
>>>> iterable objects with the same level of syntactic sugar as opApply 
>>>> gives me.  For
>>>> simple cases this is already true and I have begun converting some stuff.
>>>> However, for more complicated cases, opApply is still a lot more flexible.
>>> opApply isn't going away. For one thing, it works very well with
>>> recursive data structures.
>> 
>> So besides performance, what advantages does using ranges instead of 
>> opApply for
>> iteration over structs/classes offer?  According to some testing that I just
>> finished on the hash table implementation I was talking about earlier 
>> today, the
>> penalty for using opApply is small enough that, if using ranges 
>> requires a bunch
>> of extra bookkeeping overhead that opApply doesn't, then opApply can 
>> reasonably be
>> faster.
> 
> Speed is a small part of the equation, in fact a perk only. Ranges are 
> composable; you can combine them to e.g. do parallel iteration over two 
> ranges. Ranges really open std.algorithm to all data structures. I find 
> opApply incredibly obtuse and fostering bad design. I wish it goes away.
> 
> Andrei

But if it goes away, that'd prevent a lot of cool things that could be 
done with foreach. You could create a template that automatically 
distributes iterations to various threads with very little code 
(assuming the loop delegate is pure):

	foreach (i; paralelize(myArray))
		doSomethingComplicated();

All the complexity would lay in the opApply. You can't do this with ranges.

Other possible things involves a rudimentary profiler (checking for the 
elapsed time at each loop iteration), or a progress monitoring template 
(notifying another thread of the progress of a particular task).

	foreach (task; progessUpdater(timeProfiler(listOfTasks)))
	{ ... }

For basic data manipulation algorithms, ranges are better. But for more 
fancy stuff, opApply still rules.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/