OakLeaf Systems: Changes on the Way for VB 9.0 and XLinq

Sunday, March 05, 2006

Changes on the Way for VB 9.0 and XLinq

The January 2006 technical preview of Visual Basic 9 and Language Integrated Query (LINQ) is about to reach its second month of existence, but the XLinq team has already announced a syntax change for VB 9 XML literals. According to Avner Aharoni, a program manager for WebData XML team, there will be "a new syntax for these late-bound [XML literal] properties. Angle brackets now wrap the Xml member name so it is clear that the name refers to the elements with that name. For example Person.<Name> returns the elements called Name in the above document. ... In addition to this change in the axis members’ syntax, we are planning to change the binding of the Xml attribute member @ to XLinq’s Attributes method as opposed to the Attribute method as the compiler did in the January CTP." From Avner's response to a reader's comment [emphasis added]:

Our design goal is to make the Xml axis members experience as close as possible to regular CLR members, so users have a very easy learning curve. Our preference was to avoid the special syntax for Xml members, however because of the ambiguity and double colon problems we had to choose special syntax. We want users to continue using the most intuitive way to access members, which is the "Dot". Our plan is to add the known Xml members to the intellisense drop down so that the Xml members and the new syntax are easily discoverable. We hope that the new syntax will contribute the intellisense experience since the Xml members will show up in the same area due to the sorting of the intellisense members.

You can read more about the forthcoming changes to XLinq and the VB 9.0 compiler in Avner's "VB 9.0 Xml Features - latest update" post to the XML Team's blog.

Mike Champion took over Dave Remy's duties as XLinq program manager in mid-January 2006. (Dave is now the Group Program Manager for the XML Team.) According to his "New LINQ / XLinq Links" post, Mike continues to own the XML "DOM and the business case for XQuery in the mid-tier." Only time will tell if there is a "business case for XQuery" in the .NET Framework 3.0 or later; XLinq has the potential to handle the most common use cases for XQuery 1.0. In the meantime, Mike will be updating the "XLinq Overview" whitepaper that was included with the original (PDC) LINQ technical preview.

Visual Basic 9.0 might lose the expected lambda functions feature if the VB syntax problems for single- and multi-statement lambdas that are outlined in Paul Vick's pessmistic February 13, 2006 post can't be worked out. As Paul observes, the "Just because it comes in your size, doesn't mean you should wear it" admonition applies to programming languages, as well as to clothing. From Paul's response to a reader's comment [emphasis added]:

We're definitely started with nested functions and working our way forward, since nested functions give us at least the variable capture semantics that we need to properly do stuff like LINQ. So I would expect (but won't promise) that nested functions will make an appearance in VB. The question really is about the next step -- moving the nested functions inline. True lambda functions might not be so bad, and we're looking at some options. What looks really difficult is multi-statement lambdas. It's not so much an issue with line continuations (although we're looking at that issue too, given the length of LINQ query statements), but more with block delimiters. The fact that VB uses words for block delimiters makes inline multi-statement lambdas look pretty wordy. I'm not saying the issues are insurmountable -- we're still designing it -- just that it's not an entirely obvious piece of work...