Re: approaches for embedding a data language in a general purpose language

On Oct 10, 1:13 pm, mishad_w..._at_hotmail.com wrote:
> > I haven't yet seen an OR/M that didn't strike me as something
> > akin to those little inflatable duck rings you put on kids to get them
> > used to the pool.I love this analogy!
>
> > They push the programmer hard in the direction
> > of thinking in terms of "get the data back from the dbms; turn it in
> > to objects; modify those objects; update" even though that approach
> > is not typically the right choice.Exactly.
>
> LINQ is better, in this regard, though the new ADO.NET v3 O->RM
> framework that is layered over it seems to be a typically flawed O->RM
> implementation.
>
> To implement LINQ Microsoft extended C# to support anonymous tuple
> types, so it is possible in LINQ to just write the query to get the
> data you want and get the data back in a typesafe manner.

Yes, this is an important issue. Most statically typed languages are nominally typed, (the name of the type is the identity of the type.) Whereas SQL is structurally typed. Without an anonymous tuple type, every query requires a type that has to be given a name. :-(

However, what I consider most interesting is the idea of a structurally typed general purpose language...

> The LINQ query syntax is still horribly SQLy, with some OQLism thrown
> in, and it retains NULL, 3VL. I _think_ (though I'm not sure) that the
> intent at least is to have decent updatable view support, which is
> something, I guess.

I wonder what "decent" amounts to?

> Unfortunately, while some of the features added to C# for LINQ are
> useful in other contexts (better lambdas, limited type inference,
> limited expression trees/currying), I don't think its possible to write
> your own DSL (for a TTM-style "D" sublanguage, for example) using those
> features.

Agreed.

> For example, AFAICT, you can't define a generic function JOIN
> that takes two (anonymous typed) tuples and returns another (correctly
> though anonymously typed) tuple which is the tuple-join result.
>
> It _might_ be possible to do that in Managed C++ (I think ISO C++
> template metaprogramming could provide the type deduction).

Yeah, I used to think it might be possible with C++ too, but it turns out it isn't. For the type for the generic natural join, the return type
is a function of the parameter types. C++ can have generic functions that have parameterized types, but the resulting types can only be simple substitutions of the parameters; it's not possible to generate new types as computations on parameter types. To do that you need a full dependent type system, such as exists only in the laboratories at this point. Actually most research languages can't do it either.

Marshall Received on Wed Oct 11 2006 - 07:59:41 CEST