Linq "into" and "let" equally???

[Alexander Vasilevsky]

Linq "into" and "let" equally???

http://www.alvas.net - Audio tools for C# and VB.Net developers

[Jon Skeet [C# MVP]]

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail]:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a *single* range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a *new* range variable. So,
for instance, you could do:

var query = from x in Enumerable.Range(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

it will fail, because at the "x+y" stage "x" is no longer available.

(I haven't tried the above code yet - I'm about to do so when I've
installed 3.5 onto my laptop.)

Jon

[Marc Gravell]

Sorry, what?

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail]:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a single range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a new range variable. So,
for instance, you could do:

var query = from x in Enumerable.Range(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressioninto <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

On Nov 23, 9:27 am, "Frans Bouma [C# MVP]"
<[e-mail]:

But if you do:

var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressioninto <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

It's a good indicator that the only thing you care about from the
previous query is the actual result of the select - no intermediate
stuff needs to be propagated. (This could also make things a bit more
efficient in some cases, although that's rarely an issue.)

I'd personally write it as two queries:

var firstQuery = from x in source where blah select foo;
var secondQuery = from bar in firstQuery where ...;

which is basically the same thing, but a bit clearer IMO. There's room
for personal preference though :)

Jon

[Alexander Vasilevsky]

Thank You! Very good example!

http://www.alvas.net - Audio tools for C# and VB.Net developers
"Jon Skeet [C# MVP]" <sk***@pobox.com???????/???????? ? ????????
?????????:
news:c0**********************************@o42g2000 hsc.googlegroups.com...

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail]:

>Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a *single* range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a *new* range variable. So,
for instance, you could do:

var query = from x in Enumerable.Range(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

it will fail, because at the "x+y" stage "x" is no longer available.

(I haven't tried the above code yet - I'm about to do so when I've
installed 3.5 onto my laptop.)

Jon

[Alexander Vasilevsky]

Why painful?

http://www.alvas.net - Audio tools for C# and VB.Net developers
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl???????/???????? ?
???????? ?????????: news:xn***************@news.microsoft.com...

Jon Skeet [C# MVP] wrote:

>On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail]:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a single range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a new range variable. So,
for instance, you could do:

var query = from x in Enumerable.Range(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressioninto <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Frans Bouma [C# MVP]]

Alexander Vasilevsky wrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with cursors
because they don't understand how set-oriented languages work.

FB

>

"Frans Bouma [C# MVP]" <pe******************@xs4all.nl>
???????/???????? ? ???????? ?????????:
news:xn***************@news.microsoft.com...

Jon Skeet [C# MVP] wrote:

>On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail]:
Linq "into" and "let" equally???
>
Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?
>
I'll assume you mean "select ... into". They're not quite the
same. When you do "select ... into" you have a single range
variable at that point; any previous range variables are gone,
basically.
>
If you do "let" then it just introduces a new range variable. So,
for instance, you could do:
>
var query = from x in Enumerable.Range(0, 10)
let y = x*2
select x+y;
>
But if you do:
>
var query = from x in Enumerable.Range(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone
want to use that construct in that way...

I mean: why would anyone use select <expressioninto <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with cursors
because they don't understand how set-oriented languages work.

I don't see how it keeps people in an imperative mindset. It allows
them to express that the sequence which is the result of the "select"
is all they need for the next part of their query.

LINQ isn't actually set-oriented - it's sequence-oriented, a pipeline.
It may be convenient to think in terms of sets when writing LINQ to
SQL, but LINQ to Objects should *definitely* be considered in terms of
sequences.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with
cursors because they don't understand how set-oriented languages
work.

I don't see how it keeps people in an imperative mindset. It allows
them to express that the sequence which is the result of the "select"
is all they need for the next part of their query.

LINQ isn't actually set-oriented - it's sequence-oriented, a
pipeline. It may be convenient to think in terms of sets when
writing LINQ to SQL, but LINQ to Objects should definitely be
considered in terms of sequences.

A query which is executed on a db, will end up as a set-oriented
statement. If you write your query as imperative as possible, you WILL
probably have a slow query. A query written to be executed on a DB
should be written with set operations in mind, otherwise you will end
up sooner or later at the wrong end of the DBA-developer conversation
where you need to optimize the query to make it performing properly but
you don't know how.

FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe******************@xs4all.nlwrote:

LINQ isn't actually set-oriented - it's sequence-oriented, a
pipeline. It may be convenient to think in terms of sets when
writing LINQ to SQL, but LINQ to Objects should definitely be
considered in terms of sequences.

A query which is executed on a db, will end up as a set-oriented
statement.

Yes. And a query which is executed in-process will end up as a
sequence-oriented statement.

If you write your query as imperative as possible, you WILL
probably have a slow query. A query written to be executed on a DB
should be written with set operations in mind, otherwise you will end
up sooner or later at the wrong end of the DBA-developer conversation
where you need to optimize the query to make it performing properly but
you don't know how.

It depends on what you mean by "as imperative as possible". I don't see
"let" as being particularly imperative - you could regard it as
assigning an alias. The test queries I've done against LINQ to SQL
(which aren't many, admittedly) look fine to me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Jon Skeet [C# MVP]]

On Nov 26, 8:33 am, "Frans Bouma [C# MVP]"
<[e-mail]:

It depends on what you mean by "as imperative as possible". I don't
see "let" as being particularly imperative - you could regard it as
assigning an alias. The test queries I've done against LINQ to SQL
(which aren't many, admittedly) look fine to me.

Example: (I used 'from' here to make it more clear, I also could have
used let, it would result in a SelectMany as well)

No, "let" doesn't result in SelectMany - it results in another Select.

From the spec:

"A query expression with a let clause
from x in e
let y = f
....
is translated into
from * in ( e ) . Select ( x =new { x , y = f } )"

Does that change your opinion of it?

Jon