Lambdas and type/variable checking

Lambdas and type/variable checking

• nhanson

  Yeah, the paper didn't delve into specifics.  A quick jaunt with Reflector shows more or less why. ;)
  
  Previous comments from the C# team allude to work to make it easier for third parties to leverage the expression trees to construct queries.  Also, if you search this forum, you'll see that Ron's working on implementing DLinq for C#2. 
  
  
  

• Jiaquan Ma

  >> It is possible to write an expression that compiles to a legal expression tree that cannot be translated to SQL by DLINQ
  
  This all sounds very similar to Lisp S-expressions and Lisp Forms.  :-)
  
  >> You still get the advantage of strong typing.  However, the C# compiler has no knowledge about the extent to which your API may be able to interpret the expressions.
  
  Doesn't this beg for some sort of a compiler extensibility feature to allow third parties to verify the basic "correctness" of the expression tree at compile time   Or perhaps the expression trees are so dynamic in nature they couldn't be evaluated at compile time
  

• Coool123

  The C# compiler will not do any special validation for the API (such as DLINQ) that uses expression trees.  It will however, validate that the code in the lambda is technically legal, such that if it were executed locally as code it would be legal. 
  
  It is possible to write an expression that compiles to a legal expression tree that cannot be translated to SQL by DLINQ.
  
  You still get the advantage of strong typing.  However, the C# compiler has no knowledge about the extent to which your API may be able to interpret the expressions.
  
  

• Chubbly Geezer

  I always thought it would be useful for providers to be able to evaluate what functions they knew about.  Part of DLinq is, as I recall, taking the tree and dividing out the chunks that can be done server-side, and those which must be done locally, and optimizing the meta-query-plan thereby.
  
  (Of course, I'm still rooting for the ability to pass the tree as-is to Yukon...)
  
  
  

• Rajasekhar

  That's the intent, I believe.
  
  Have you reflected on the expression tree that is constructed (eg, set a breakpoint in the debugger)
  
  The compiler need not know what's valid for your particular backing store.  Based on my take on DLinq, it's the job of the adapter you write to convert the tree into zero or more queries of the store, plus maybe some client-side code to take care of what the store cannot.  The compiler itself remains oblivious of the capabilities of the store, even if it's MSSQL.
  
  
  

• Victor DelPrete

  The whole point of LINQ is to provide compile time checks rather than handling queries as a quoted string.  So, there must be some way to validate the expression tree at compile time.  With DLINQ they create classes that map to tables and some tricks under the covers to make the from clause connect to the other clauses.  I did not see this treated in the existing whitepaper presented at PDC which was pretty high level.  I am looking for some pointers on how to leverage this for our types.
  
  

• Wislars

  In our modeling product we have an extensible compiler that has worked out quite well.  The compiler interacts with a MetaModel (one of which is a CompositeMetaModel which allows chaining of any number of MetaModels to be treated as one).  The MetaModel abstracts the knowledge of what the underlying semantics are.  There is a corresponding ObjectModel at run-time to perform complementary semantics.  This allows a plug-in to map the compiled syntax to custom semantics on objects owned by that plug-in.  This allows things like association traversal accross a database join table, or an object pointer, to be unified using a "." notation.  Our run-time is not as complex as the CLR since we run on top of the VM not in it, but it would be very useful to have the C# compiler implement something like this for Lambda expressions.
  
  
• Lambdas and type/variable checking