Lambda the Ultimate

I honestly don't see how this is a bad think for MSFT stock options...but I suppose that's for another forum.

As mentioned in the original write-up, this looks like list/monad comprehensions of many functional languages (I guess I'll continue my tradition of mentioning the paper "Comprehending Queries" in every post I make :) ).

Also, when Anders showed 'anonymous types' where attributes from one type can be projected to another type...on the fly (without first defining a class)...it looked exactly like he was using tuples (records actually) of existing functional languages. From what I understand, tuples and records are the basic components on which other features such as linked lists and classes are built...C# 3.0 will introduce them as a very high level component...interesting...makes you wonder how beneficial it would be just to allow raw tuples/records in the language.

I haven't actually written a program in FP yet. It seems by the time I do some reading on it, C# (and may be Java?) will have become 'functional' themselves :).

Another thing I have noticed is that much of the functionality added to Java and C# recently has been of syntactic nature (syntactic 'features' and compiled away to some more fundamental operations). I wonder how fast these mainsream languages will evolve if end users could extend syntax themselves (similar to LISP macros).

Can you point to any more documentation for the "general meta-programming framework in the language", please? Does this imply that any end-user could write a DLinq-equivalent DSL, or does it require privileged access to the compiler?

The idea is pretty cool I think :-)

There is an object model for fully resolved expressions and delegates. C# then adds a conversion from lambda expressions to these expression trees.

For example, the following declaration will create an expression tree that represents the function (x) => x > 2 and assign it to foo:

  Expression<Func<int, bool>> Foo = (x) => x > 2;

  public static IEnumerable Where([this] IEnumerable source, Func predicate);
  public static Query Where([this] Query seq, Expression> pred);

  src.Where((x) x > 2)

Of course, you can build expression trees yourself by directly calling the underlying System.Expression API.

Hope this helps,
Erik

Also, if you download the LINQ preview, it comes with a fun sample showing how to implement a DSL with C# 3.0 (in this case, a logic programming language).

"Higher-order functions? Though it's nice that they are achievable, they are not really needed. I've successfully programmed many applications using nothing more than GOTO. I never understood..."
OK, you can finish the rest in your mind.

"Goto" plus creative uses of the stack achieves much the same effect, so the statement is valid. (In a sense.)

You only need higher-order functions if you care about ensuring correctness.

The strength of a programming language lies into the fact that all these features can be expressed in terms of the core constructs, and not with extending the compiler. If a compiler needs to be extended to support 'map' (for example), then the language clearly had a problem in the first place.

These problems can be overcome, of course. But better language and tools will help.

I think that all the things you mention, although it's nice that
they are achievable, they are not really needed. I have successfully
programmed many DB applications using nothing more than raw ODBC

Who didn't? But when it comes to real huge applications (in a software engineering-sense, not in a semi-pro sense) you're gonna want to have at least an O/RM unless your customer(s) pay(s) per hour, have unlimited cash and don't ask questions.

and JDBC using plain recordsets. Even Hibernate seems an unecessary
luxury to me. I never understood why people need these obscure
object models, where plain recordsets are more than enough.

I need to tell you that you have a giant lack of understanding which may have lead to your reserved attitude. You *can* do everything with records sets, basically you can do everything with a machine that is turing-complete but that's not the point. LINQ is quite sophisticated (alas it is not new as its roots lie in the ML type system) and saves a lot time. Using LINQ I am able to finish an application before you even finished the prototype.

I've got to hand it to you though: I've never seen so many buzzwords
in one post.

"Buzzword" means there's no real value behind it. But that's not true. C# 3.0 can infer types from expressions which is really new for C-/Java-like languages and is a huge advantage compared to untyped scripting languages.

By the way, the more a language is extended with features, the more
wrong it gets. In programming languages, less is
more...

You're wrong. C# 3.0 is going in the right direction. The more abstract I am able to express certain problems the easier it is to understand the resulting software architecture. You wouldn't do a DB-Application in x86-Assembler, would you? On every subroutine you had to think about things like register allocation or instruction scheduling. The Compiler does that for you. Without O/RM or LINQ you first create a db scheme, then write code to transfer relational data into objects, resolve references and stuff like that. That's a mechanic task - why would you want to do it yourself if a tool (i.e. Hibernate) can handle that?

unfortunately, people don't get it, and we end up with big ugly
frameworks that everybody thinks they are necessary but nobody knows
how to use properly, besides the fact that they add layers upon
layers of useless code...

If it is useless, drop it. But unless you can give evidence on that you can handle large software projects without even self-written frameworks (which ultimately results in a copy-and-paste architecture, as framework means abstraction per se...) please don't put such nonsense statements on this site. There a lot of people out there earning money for programming db-applications but that doesn't mean they're doing a state-of-the-art job.

LINQ is a language design approach, so I am not sure I understand why you find that to be less on topic for LtU.

As far as I can tell LINQ is by itself an effort to integrate query facilities into the .NET framework, especially with respect to XML and RDBMS. In order to make effective use of these query facilities VB9 and C#3 have been extended with features, like higher order functions, local type inference etc. These extra features will probably have a larger scope than LINQ, hence the seperation I made into language extensions and LINQ. Ltu being devoted to programming languages and given the fact that the programming language extensions have a larger scope I would opt for looking at the language extensions primarily. But of course that is only a suggestion.

I thought you meant something else.

Eval[[o.m(...,a,...)]] = Eval[[o]].(m.Name)(...,Eval[[a]],...)

The usual complaint about proxying/wrapping is having two different object identities - testObject and testWrapper. Depending on the application this may or may not be a problem.

No, there are no CLR changes involved in Linq (the preview works on the v2.0 beta2 CLR). It seems likely that we may ship some of the core Linq interfaces with the Orcas (post v2.0) framework, but it's highly unlikely there will be any CLR changes for Linq in the Orcas release. Concepts like "nullable" were added in the v2.0 CLR and C# compiler partly in preperation for Linq.

This is one of my long-time wishes for OO programming... Have you ever looked at Scala's views? They're obviously trying to reach this goal as well, and it's a pretty cool technique, although it strikes me as too much of a bolt-on hack to be a really elegant answer.

But there are a lot of questions I have about these kinds of features. How, for example, should these interface extensions be scoped? Statically? Dynamically? Obviously some kind of dynamic scoping is needed, because once an interface is extended, it would need to be available with the new interface when passed to functions and so on. But what should the dynamic scope of the extension look like? The whole program? What if different parts of the program want to add the same extension with different implementations? That doesn't make sense for your example, but it certainly does make sense in other cases...

Incidentally, this is something I've thought about a lot, and it's what I had in mind when I was reading the ContextL paper as well...

I am aware of them, but haven't studied them yet. You raise very good questions. My hunch is that a solution will be influenced quite a bit by type inference considerations.

I'm not sure about dynamic interfaces, but the typed equivalent of duck typing is commonly called structural subtyping. OCaml has it: A class is a subtype of another if it supports the operations of the parent, rather than if it is explicitly declared as so.

see Andreas Rossberg code

I'd say the language of your choice rather has a severely broken object system (which seems to use a certain amount of nominal typing btw). Here is your example in OCaml:

# class inch d =
  object
    method to_cm = d*.2.54
    method to_inch = d
  end;;
class inch : float -> object method to_cm : float method to_inch : float end
# class cm d =
  object
    method to_inch = d*.0.3937
    method to_cm = d
  end;;
class cm : float -> object method to_cm : float method to_inch : float end
# let a = new inch 10.5;;
val a : inch = <obj>
# let b : cm = a;;
val b : cm = <obj>
# b#to_cm;;
- : float = 26.67

vb9 dynamic interfaces use system.reflection so it's late binding.
Ocaml structural typing is early binding.

O,caml static type system renders runtime type mismatches impossible, and thus obviates the need for runtime type and safety checks that burden the performance of dynamically typed languages, while still guaranteeing runtime safety
OCaml delivers at least 50% of the performance of a decent C compiler,

When c is a database table, the LINQ version will perform the computation on the server side.

(Other than that, LINQ is not interesting.)