[IronPython] LINQ from IronPython

[Keith J. Farmer]

I greatly prefer the C#-ish import rather than "clr.Extend".  Beyond that, explicitly importing the extending class could have benefits that were noted back when LINQ was introduced:  it's possible for a single namespace to have conflicting extension methods.  The moment there's conflict, you lose the extension method syntax.  Therefore, my suggestion is for the second method (and not for the IMHO-abused "explicit better than implicit" reason people give).

As for expression trees:  I wouldn't expose the DLR's AST.  Instead, I would expose the same trees that C# and VB expose.  The reason being, of course, is that these would be what mainstream LINQ implementations would target, LINQ to SQL in particular.  For the most part, that should be a simple transformation, and could be performed at runtime.  That is, implicitly replace a call:

	MethodExpectingExpressionOfFunc(lambda x: x.Foo + x.Bar)

with

	MethodExpectingExpressionOfFunc(DlrToClrExpressionConverter(lambda x: x.Foo + x.Bar))

.. and not worry about it.  If you *do* want to worry about it (ie, you wouldn't want to lose the "this was a dynamic call" knowledge), I could see some sort of pragma to modify that behavior, or an explicit NonLossyDlrExpressionConverter that bypasses implicit expression tree conversion.


Let's face it:  there are plenty of *static* methods that LINQ to SQL and friends cannot handle, because there is no translation possible to their target.  We cannot expect to do any better.  But we *can* talk the same dialect of the same language.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Tuesday, December 22, 2009 10:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] LINQ from IronPython

Jeff wrote:
> Extension Methods

Personally I like the 2nd option.  I think only the 2nd and 3rd are
really viable.  The one important thing to keep in mind here is that
importlib may become the default importer in the future.  So any hooks
here need to be based off of the processing of what the import machinery
brings back - not something buried deep in the import machinery.  The 2nd
form means we only need to check the type going back vs. it's entire 
namespace which will be more expensive.

The 3rd option could also be done w/o myObj, e.g. you just say bring
in this type or namespace.  It could also be global (not very nice) or
it could be local to the module like the other forms presumably are.

Jeff wrote:
> Expression Trees (C# lambdas)

We certainly have the raw AST available to us at all times except for
when we've pre-compiled code.  We don't expose this directly today just
because it's a big implementation detail to bleed out.  Exposing a 
conversion of functions to Experssion<T> though might be a really good
way to expose it w/o exposing all of the implementation details.

The biggest problem w/ exposing our AST though is can anyone else do
something useful with it?  If they're just going to compile the AST
and run it then that's fine.  But if they want to take the AST and
send it off to the database as a query things aren't going to work
so well at this point simply because they won't recognize the dynamic
nodes.  There's also some situations where we open code to the dynamic
nodes as call sites then things are really confusing.  This may
be fine for this case where the conversion is explicit and the user
can make sure it works.