DLR Trees (Part 1)

re: DLR Trees (Part 1)

Steve Maine — Wed, 16 May 2007 00:52:40 GMT

How do you guys think about DLR trees vs something like System.Expressions?

re: DLR Trees (Part 1)

Robert Brewer — Wed, 16 May 2007 02:52:26 GMT

That is indeed a powerful technique. I use a similar one for Dejavu/Geniusql to translate Python expressions into SQL. Would your DLR implementation be easier if Python had a first-class "expression tree" object? I'd love to work on a PEP for such a beast. I'm stuck passing lambdas into my Expression objects for the moment (although I expect to support genexps soon for the common case of relation-attribute-restriction 3-tuples like SQL SELECT uses). And having a simple symbolic syntax instead of the "lambda" keyword would make that kind of thing much more readable...

re: DLR Trees (Part 1)

j marlowe — Wed, 16 May 2007 03:56:56 GMT

small typo in your code, should be factorial(n-1) not fact(n-1)

oh i forgot dynamic-language guys enjoy finding errors at runtime... keeps things interesting :)

re: DLR Trees (Part 1)

Programmer — Wed, 16 May 2007 12:20:40 GMT

Hmmm, code as tree... Oh dude, congratuations, you just reinvented Lisp! Maybe Microsoft can patent it now and litigate the hell out of all the CS departments.

re: DLR Trees (Part 1)

malcontent — Wed, 16 May 2007 14:50:31 GMT

I am sure MS has patents on the DLR, I wonder if they will indeed start suing people who use LISP or run programs written in LISP.

Actually a more interesting question is whether MS will sue you if you write an open source application using the DLR.

re: DLR Trees (Part 1)

Ice Moose — Wed, 16 May 2007 23:53:12 GMT

Since when LISP holds exclusive rights on representing expressions as trees?

Plus, LISP's s-expresions are not exactly "code as tree" (unless some particular implementation is being referred to); it's rather "code as data".

Expression trees in DLR (or is it actually .NET 3.5?) are supposed/expected to be language agnostic, yet, as mentioned in the post, a particular language run-time is free to apply its own optimization and execution strategies.

re: DLR Trees (Part 1)

ArtVandalay — Thu, 17 May 2007 06:54:05 GMT

Y'know, using a comment to point out a similarity between "code as tree" and Lisp isn't at all clever or insightful when the poster himself wrote "Anyone who's programmed in Lisp or Scheme knows this trick extremely well."

Not to mention that parsing code into an expression tree is the front end of pretty much every compiler since, I don't know, the introduction of BNF...

One would (strenuously) hope any associated patents would be shouted down by the overabundance of prior art.

re: DLR Trees (Part 1)

Miguel de Icaza — Tue, 22 May 2007 09:03:27 GMT

malcontent,

Read the MsPl license, section 2.b, where there is an explicit patent grant for technologies covered by the DLR.

re: DLR Trees (Part 1)

tomasp — Thu, 24 May 2007 11:47:34 GMT

Hi Jim,

from the sample you posted it looks that DLR treats expressions and statements as different types, so I'm wondering if your AST would be able to represent following F# code:

let a = 1 +

if (b=c) then

print_string "side effect 1!";

else

print_string "side effect 2!";

In F# everything is an expression, so you can embed statements anywhere in the tree. You can write code with same semantics in JavaScript, so there will be *some* way for representing it, but it's quite an ugly trick ;-):

var a = (b==c)?

(new function() {

print_string "side effect 1!";

return 3;

})():(new function() {

print_string "side effect 2!";

return 4;

})()

Tomas

re: DLR Trees (Part 1)

xiao — Sun, 03 Jun 2007 08:50:27 GMT

I'm waiting for Part 2 .........

Papa fritas, cervezas y una babel de esos raros lenguajes nuevos

Angel "Java" Lopez — Wed, 17 Sep 2008 14:55:42 GMT

Gracias a la gente de Microsoft de Argentina, en especial al bueno de Miguel Saez , tendré el gran gusto

New and Notable 167

Sam Gentile's Blog — Wed, 03 Dec 2008 05:50:22 GMT

You have to love a hotel where you have the amazing Lavazza coffee in your hotel room. CLR/Silverlight/Orcas/C# One of the things that has been a bit fustrating over the years with the CLR is the limitation of one CLR per process. Specifically, where