• bearophile <bearophileHUGS lycos.com> Feb 03 2008
• Michiel Helvensteijn <nomail please.com> Feb 03 2008
• bearophile <bearophileHUGS lycos.com> Feb 03 2008
• Don Clugston <dac nospam.com.au> Feb 04 2008

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

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

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

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.