On 11/27/2010 5:32 PM, BLS wrote: > On 27/11/2010 23:16, spir wrote: >> Maybe the example does not show what you actually mean, but I do not >> see any advantage. Version plain D is close to perfect, obvious, >> direct; version embedded DSL just adds noise (and work for >> implementing the feature, and work for a precompiler or whatever...). > > 1-How do you implement LINQ in D ?
AFAIK, LINQ is _not_ SQL embedded into C# or VB. It's a mechanism that allows C# to examine expressions (written in C#, as strange as they might look) and translate them to SQL (or whatever). LINQ can take two forms. First: var query = from s in names where s.Length == 5 orderby s select s.ToUpper(); Second: var query = names.where(s => s.Length == 5) .orderby(s => s) .select(s => s.ToUpper()); They are semantically identical, but I like the second syntax much more, because it uses existing language features, works with auto-completion and is much more readable in complex cases. To support something like that a language needs to have tools for introspection of its own code. > 2-Having such an compiler plugin architecture, will enable you f.i to > seamless use Go, Lisp whatever within D. > > 3-Even if these plugins (please note > more than one) are just for SQL, > you got database access for free. LINQ for databases is a bit overrated. Writing real SQL queries is often simpler. LINQ query generator does some optimizations, but it also screws up in some cases. LINQ to objects is a different story, because it allows for much nicer declarative syntax to do mapping and projections. > 4- I am using such an EBNF driven tool (almost written by me) to > translate SQL scripts. // Create a new db from firebird to mssql.. > including stored procedures, triggers etc. > > So sorry Denis, I know what I am talking about. > Bjoern
