www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linq and the like

reply bearophile <bearophileHUGS lycos.com> writes:
LINQ (and its future parallel extensions), with its additional syntax, may be a
good thing to add to D:
http://www.moserware.com/2008/02/for-loops-using-i-i-enumerators-or-none.html

You can use the same syntax to simplify parallel code, DB access code, etc.

Bye,
bearophile
Feb 03 2008
parent reply Michiel Helvensteijn <nomail please.com> writes:
bearophile wrote:

 LINQ (and its future parallel extensions), with its additional syntax, may
 be a good thing to add to D:

 
 You can use the same syntax to simplify parallel code, DB access code,
 etc.

Can't D already do this? It has lazy evaluation of function literals, so the container class just has to implement the count method. Even C++ can do this, though it looks more messy. Anyway, I disagree with the author about (at least) two things. * I am one of those people that use the pre-increment operator in for-loops. I know it doesn't improve performance for integers, but it does for iterators. So I just use it everywhere for consistency. * While I agree that when a foreach-loop is possible, you should use it, it can never completely replace the for-loop, because it is simply less powerful. Any number of sorting/searching algorithms still need for-loops. -- Michiel
Feb 03 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Michiel Helvensteijn:
 Can't D already do this?

D 2.x has closures, that's a good starting point, but some things are missing still: - A built-in support of the methods LINQ accesses in AAs, Arrays, etc. - Some external bridge, so it can be used on DBMSs too. - Some sugar for its short syntax, you can see it here: http://en.wikipedia.org/wiki/Language_Integrated_Query#Language_Extensions - Multi-processing management for the parallel LINQ. So as you can see it requires many more things, that's why it's actually useful.
 * While I agree that when a foreach-loop is possible, you should use it, it
 can never completely replace the for-loop, because it is simply less
 powerful. Any number of sorting/searching algorithms still need for-loops.

I agree. And LINQ syntax is slow, so you can't use it in the inner loop of something that has to run fast. The basic idea is that D can have both high-level constructs beside keeping the low-level ones. Bye, bearophile
Feb 03 2008
parent Don Clugston <dac nospam.com.au> writes:
bearophile wrote:
 Michiel Helvensteijn:
 Can't D already do this?

D 2.x has closures, that's a good starting point, but some things are missing still: - A built-in support of the methods LINQ accesses in AAs, Arrays, etc. - Some external bridge, so it can be used on DBMSs too. - Some sugar for its short syntax, you can see it here: http://en.wikipedia.org/wiki/Language_Integrated_Query#Language_Extensions - Multi-processing management for the parallel LINQ. So as you can see it requires many more things, that's why it's actually useful.
 * While I agree that when a foreach-loop is possible, you should use it, it
 can never completely replace the for-loop, because it is simply less
 powerful. Any number of sorting/searching algorithms still need for-loops.

I agree. And LINQ syntax is slow, so you can't use it in the inner loop of something that has to run fast. The basic idea is that D can have both high-level constructs beside keeping the low-level ones. Bye, bearophile

AFAICT, there's nothing in LINQ that D couldn't (in theory*) do with a library -- today implemented using ctfe and mixins, in future with the front end replaced by macros. IMHO, LINQ is a classic example of something that should be in a library. If it can't be implemented in a library, then the solution is to make the language more powerful, not to shove the library into the compiler. * not in practice, mainly because of the compiler CTFE bug: temporary strings never get deleted, so CTFE runs out of memory extremely quickly.
Feb 04 2008