On Sunday, 13 September 2015 at 03:03:44 UTC, Andrei Alexandrescu
wrote:
Yah, understood. Problem here is the approach is bound to run
into walls at every few steps. Say you fix the comparisons to
work. Then you have operators such as LIKE that are necessary
like(Person.Name,"peter%")
Person.Name == pattern("peter%")
yet not representable in D. So more tricks are in order. This
is what I've seen with ET in C++ - an endless collection of
tricks to achieve modest outcomes at enormous costs.
FWIW, Guido wrote a similar query language to what Martin
proposes for Google App Engine called NDB:
https://cloud.google.com/appengine/docs/python/ndb/queries
They already had a string query language called GQL:
https://cloud.google.com/appengine/docs/python/datastore/gqlreference
I never use GQL, because the NDB solution is superior in every
way.
GQL is only for the REPL.
2. If you want to embed real SQL into D, use string-based
DSLs.
Strings don't capture context, aren't typechecked, and require
a complex
CTFE parser.
db.get!Person.where!"age > 21 & name = ?"(name);
Understood as well. I figure from the example you have binding
in mind, which is good. At some point you need to bite the
bullet and write a parser for the relational query language you
want there.
No. D should stop abusing strings. Strings should never contain
references to type names. It makes it impossible to transpile D
in the general case.
Walter is unlikely to change his mind on opCmp, because he has
put a lot of emphasis on that restriction since D1, but I think
he overreacted on some C++ libraries being less than user
friendly.
The only thing you achieve is that people will create even uglier
hacks to get what they want, like using a thread local global AST
root pointer and build the AST as hidden side effects at runtime
instead.
