Select/From vs. From/Select revisited…

We’ve been hard at work on an updated CTP of the LINQ work, and when you get it (no comment on dates at this point), you’ll notice several new things about the VB LINQ support. One the biggest is going to be the fact that, after trying all the Intellisense tricks we could think of, we’re throwing in the towel on Select/From and adopting the “Yoda style” From/Select syntax. As in:

        Dim WACusts = _

            From c In Customers _

            Where c.State = “WA” _

            Select c

instead of:

        Dim WACusts = _

            Select c _

            From c In Customers _

            Where c.State = “WA”

You can review the arguments for and against in my original Select/From blog entry, but the salient point is and always has been my comment that:

Statement completion is a significant question. We have a bunch of ideas as to how we could finesse this in the IDE, but we haven’t reached a point of being really able to try them out. This may be a real sticking point, time is just going to tell.

And, indeed, this was the sticking point. Many of you tried out the Intellisense support we shipped in the last CTP and found it wanting. We looked at the other options available to us and came to the conclusion that it just wasn’t going to work any of the other ways we could think of, either. So, having concluded that we did our best to get the syntax we wanted, we switched to From/Select so that we could give the Intellisense experience that we think is even more important.

26 thoughts on “Select/From vs. From/Select revisited…

  1. David Stone

    Nice. That’s a good thing, IMO. I understand the reasoning behind wanting to keep it like SQL with the Select/From. But with XLinq being such a key piece of Linq for VB.NET (Obviously. I mean, you guys are including XML literals. That’s got to mean something.), I would almost think you would have wanted to adopt the FLWOR style queries that XQuery has in the first place. It seems to me that would certainly make VB.NET a more attractive option for those who do a lot of work with XML.

    Now if you could just get rid of those underscores, the query would be a lot prettier. πŸ˜‰

    Reply
  2. Greg

    Can the SELECT and WHERE statements be reversed?

    Something like this?

    FROM Object

    SELECT Values

    WHERE Conditions

    FROM/SELECT/WHERE seems it might be easier for me to wrap my head around…

    Thanks,

    Greg

    Reply
  3. David Taylor

    Probably a good thing. It will certainnly help when comparing C# and VB code.

    People will need to get used to the FLWOR order and it does start to make logical sense.

    I have been playing around with RC1 of PowerShell (a.k.a Monad) for the first time over the last week, and the same principle applied.

    get-stuff | where something-is-true | select fields

    It really starts to seem "the right way" even since I started playing with LINQ at the PDC. I think most devs will find the consistency between PowerShell, LINQ C# and LINQ VB helps.

    Reply
  4. Ian

    It would have been nice to have VB and C# support Select/From.

    I think both supporting From/Select is fine and I’ll get used to it.

    The worst would have been VB and C# being different. I program in VB 95% of the time, but I read tons of C#. That would have been a pain.

    Whatever you do drag along the ADO.net team. Them not supporting nullable types is flabbergasting….

    Reply
  5. Anthony D. Green

    I can’t say that I’m not pleased to see this change. I think the C# team saw the advantages and went for it. I personally find

    With regards to the underscores…

    It seems to me that there are some situations where you could make the compiler smart enough to see where a logical line should physically terminate based on the physical lines around it. That’s a lexical nightmare, I’m sure but I think if you were feeling funny you could pull it off.

    I think that if you’re making a method call when you hit a ( you know that there is no possible way the logical line could terminate before encountering the closing ) so underscores within the parameter list are superfluous.

    In all honesty since method calls are most of what we do and the typical candidates for using _ it wouldn’t be a big leap.

    Likewise for array initilizers the statement can’t be over until you hit } so same deal, not a frequent case but (In this version we get those infered array initializers right:

    String.Join(",", {"Foo", "Bar"})

    As far as the query, the only real way I could say it, would be if after the Select you encounter a comma, in that context it could imply a line continuation.

    It’s a lot like the way the editor uses the As keyword as a cue to popup the type list or other context sensitive keywords like Of, . (member access), or the comma in CType/DirectCast.

    It’s a neat to have feature that would realy piss the semicons off. Maybe not where you want to put your development effort, but I’ll say this. If you could get the VS editor’s word wrap feature to respect indentation and tabs it might make this less of an issue. πŸ™‚

    Reply
  6. Rob

    Honestly, I love it. I always joke with my students, that when I rule the world, SELECT will be after FROM. It just makes more sense.

    Reply
  7. Jonathan Allen

    I can live with the new syntax. It’s a little disappointing, but Intellisense is way too important to lose.

    As for line continuations, they are definitely worth getting rid of. Please do it before its too late and the language gets something that makes it impossible to remove them.

    Jonathan Allen

    P.S. What is the deal with the ADO team? First they make us use GetOrdinal all over the place. Then they create all these SQL Types that aren’t actually used by the data readers. And now they don’t support nullable types. They really need to get on the ball.

    Reply
  8. Pingback: @ Head

  9. Pingback: Daniele Bochicchio

  10. Scott S.

    Great change in the right direction! The intellisense is so important for ease of use and discoverability.

    I have to agree about getting rid of underscore line continuations wherever possible. Seems like the parser could figure it out most of the time. Even if it is just for passing parameters and the new LINQ stuff, it would be a productivity boost.

    Reply
  11. simon geering

    Any chance of some form of "select designer" "smart region "making it into the final product? i.e something like the way SQL SELECT blocks work in SQL scripts in a VS.net database project?

    Reply
  12. Pingback: Wooley's Wonderings

  13. Jim Wooley

    I’m glad to see the change. Each time I presented the Select (no wait for it) From f in foo (now go back) method, I just got quizzical stares. Now we just need to get the SQL Server team to change their syntax to agree…

    Reply
  14. Martin Plante

    How about supporting both forms? At least at compile time? I see others have suggested this in the previous post. I don’t see an answer to this suggestion?

    Reply
  15. Steve

    To get around the _ issue how bout adding a line terminator like ";" πŸ™‚

    I like the change and am very happy that both VB.NET and C# will be on the same page.

    Reply
  16. dono

    VB.Net is a language. It can be written in any text editor; VS is not the only compatible editor. Why should a single editor dictate language syntax? Sure, when I use VS I find Intellisense useful at times, but it should not influence language design. At the language level, why not support both syntaxes. Then, from within VS, provide whatever level of Intellisense you can; that level is decided by how the user writes code. This should please the SQL-style folks as well as the Intellisense-driver folks too.

    Reply
  17. Anthony D. Green

    I think it’s absolutely critical to the very nature of BASIC that there be ";" line terminators. Though expanding the current ":" terminator might be slightly more acceptable though I still think it’s an inelegant solution. C syntax was driven by an earlier time where parsers were stupid and both memory and clock cycles were limited. BASIC has always tried to take advantage of modern conveniences – go with the clever intuitive compiler.

    P.S. It’s amazing how this blog entry has sparked an entirely different topic, Mr. Vick, I do hope you all are paying attention.

    Reply
  18. Branco Medeiros

    I completely agree that, intellisense-wise, it’s advisable to put the From clause before the Select, but I can’t understand why the Select should be the last clause in the statement. It’s place, it seems to me, is near the from clause, as someone suggested:

    From C in Countries Select C Where C.Name = "Brasil"

    It seems much better than

    From C in Countries where C.Name = "Brasil" Select C

    Besides, it seems cumbersome not having an ‘all’ or similar clause (maybe ‘*’ would do?):

    From C in Countries Select All Where C.Name = "Brasil"

    Ideally, this could be as succint as:

    From Countries Select All Where Name = "Brasil"

    The pseudo-variable (‘C’ in the previous examples) would only be necessary when you had more than one source in the select:

    From C In Countries, Y In Cities Select All _

    Where Y.CountryID = C.ID And C.Name = "Brasil"

    Regards,

    Branco.

    Reply
  19. Guess Who?

    Oops, typo, I said that I thought it was "absolutely critical to the very nature of BASIC that there be ‘;’ line terminators." I meant that I think semicolons are very UN VB and that semicolons are evil! But seriously, I like a lot of what VB is and I wouldn’t advocate turning VB into C#. And I don’t mean that I don’t want C# to be VB with semicolons and braces. Even if it is that’s fine. At least it’s different. When we start adding semicolons and cutting keywords we’re making VB C# -PERIOD.

    Reply
  20. Jim Wooley

    Branco, the issue with putting the "Where" clause close to the "From" clause is that we are often not selecting portions of the data for display or as return values that are indeed part of the query. For instance, take the following sample

    From E in Employees Select New {E.NameFirst, E.NameLast} Where E.EmployeeId = 1

    Here, if we create our IEnumerable(Of NameFirst_NAmeLast) and then try to get the EmployeeID from that, the field is not included in the query. If we do the where prior to select, EmployeeID is available as part of E. The crux of the matter is the order in which the extension methods are applied. (Granted, we have already seen how the order of the actual code does not necessarily correspond to the evaluation order of the code.)

    Reply
  21. Mike Brenner

    I see that because Intellisense enhances LINQ, you need to use a subset of SQL modified with the SELECT at the end to do the things you desire to do with Intellisense. This philosophy approaches that of Ruby on Rails, that an object library simplifies SQL (which it does for the simplest of queries, but at the expense of queries with a lot of rows or with complex SQL).

    I would like to suggest fixing Intellisense so that it can do everything LINQ requires without modifying the standard SQL language. Keep SQL intact in this new product, please.

    Reply
  22. Rory Becker

    +1 for FROM SELECT WHERE

    But….

    Is there any reason why you couldn’t make the order of SELECT and WHERE work either way?

    After all the qualifiers are all in the from anyway so the only requirement is that the FROM comes first

    Reply

Leave a Reply to Scott S. Cancel reply

Your email address will not be published. Required fields are marked *