On 2012-10-29 18:43, BLM768 wrote:
>
>>
>> You can have a look at DataMapper. That's also for Ruby but it's not
>> specific for SQL, if I recall correctly. Have a look at some ORM
>> library written in Scala, I would guess they can be quite innovative
>> and it's statically typed.
>>
>> http://squeryl.org/index.html
>> http://datamapper.org/
>
> Those libraries definitely look interesting. I should probably consider
> some type of NoSQL database support...

If I recall correctly, Squeryl use Scala AST macros to support a query syntax, that in D would look, as below:

class Person : Model { }

void main ()
{
    auto p = new Person;
    p.name = "John Doe";
    p.save();

    p = Person.where!(x => x.name == "John Doe");
}

-- 
/Jacob Carlborg

>
> If I recall correctly, Squeryl use Scala AST macros to support a query syntax, that in D would look, as below:
>
> class Person : Model { }
>
> void main ()
> {
>     auto p = new Person;
>     p.name = "John Doe";
>     p.save();
>
>     p = Person.where!(x => x.name == "John Doe");
> }

If you make x some fancy wrapper type containing more fancy wrapper types with overloaded equality operators that return some sort of Expression class instead of a boolean, you might actually be able to get this to work with only D's current features. However, that would kind of destroy the hope of efficiency. :)

What might be nice is a database written in D that completely eschews SQL in favor of a native API. I might have to play with that eventually, but I'll probably give it a while because it would be a huge project, and, like most people, I'm under time constraints. :)

On 2012-10-30 04:22, BLM768 wrote:

> If you make x some fancy wrapper type containing more fancy wrapper
> types with overloaded equality operators that return some sort of
> Expression class instead of a boolean, you might actually be able to get
> this to work with only D's current features. However, that would kind of
> destroy the hope of efficiency. :)

It can probably all be handled at compile time. The problem with this that you cannot overload the following operators: &&, ||, != and probably some other useful operators.

> What might be nice is a database written in D that completely eschews
> SQL in favor of a native API. I might have to play with that eventually,
> but I'll probably give it a while because it would be a huge project,
> and, like most people, I'm under time constraints. :)

Yeah, I know.

-- 
/Jacob Carlborg

On Tue, Oct 30, 2012 at 9:15 AM, Jacob Carlborg <doob@me.com> wrote:
> On 2012-10-30 04:22, BLM768 wrote:
>
>> If you make x some fancy wrapper type containing more fancy wrapper types with overloaded equality operators that return some sort of Expression class instead of a boolean, you might actually be able to get this to work with only D's current features. However, that would kind of destroy the hope of efficiency. :)
>
>
> It can probably all be handled at compile time. The problem with this that you cannot overload the following operators: &&, ||, != and probably some other useful operators.

&& and || can be replaced by & and |, so there is a workaround.
I feel much more limited by != and, even more problematic, !.  Maybe
unary - could be used in lieu of !.

On Tuesday, 30 October 2012 at 10:01:06 UTC, Philippe Sigaud wrote:
> On Tue, Oct 30, 2012 at 9:15 AM, Jacob Carlborg <doob@me.com> wrote:
>> On 2012-10-30 04:22, BLM768 wrote:
>>
>>> If you make x some fancy wrapper type containing more fancy wrapper
>>> types with overloaded equality operators that return some sort of
>>> Expression class instead of a boolean, you might actually be able to get
>>> this to work with only D's current features. However, that would kind of
>>> destroy the hope of efficiency. :)
>>
>>
>> It can probably all be handled at compile time. The problem with this that
>> you cannot overload the following operators: &&, ||, != and probably some
>> other useful operators.
>
> && and || can be replaced by & and |, so there is a workaround.
> I feel much more limited by != and, even more problematic, !.  Maybe
> unary - could be used in lieu of !.

There was a pull request for __traits(codeof, func) that would return the code for a symbol including lambda methods. It would probably be easier to have something like that for getting the AST and then using that to generate SQL queires (this is how C# / LINQ does it) than using sketchy hacks that go against natural language feel. Though it wouldn't be particularly easy to get that in to the compiler apparently due to AST rewriting issues.

https://github.com/D-Programming-Language/dmd/pull/953

On 2012-10-30 13:04, Kapps wrote:

> There was a pull request for __traits(codeof, func) that would return
> the code for a symbol including lambda methods. It would probably be
> easier to have something like that for getting the AST and then using
> that to generate SQL queires (this is how C# / LINQ does it) than using
> sketchy hacks that go against natural language feel. Though it wouldn't
> be particularly easy to get that in to the compiler apparently due to
> AST rewriting issues.

How would that work in this case, the code need to compile? I mean, even if you can get the syntax of a function, process it correctly and generate SQL from it, the function still need to compile.

-- 
/Jacob Carlborg

On 2012-10-30 10:59, Philippe Sigaud wrote:

> && and || can be replaced by & and |, so there is a workaround.
> I feel much more limited by != and, even more problematic, !.  Maybe
> unary - could be used in lieu of !.

How does that work with operator precedence? There's a plugin for ActiveRecord, called Squeel,  that allows you to do something like this:

Person.where do |q|
  (q.name == "asd") &
  (q.address == "foo")
end

But because of the operator precedence in Ruby you need to wrap every comparison in parentheses, not very pretty.

-- 
/Jacob Carlborg

On Tue, Oct 30, 2012 at 3:44 PM, Jacob Carlborg <doob@me.com> wrote:

> How does that work with operator precedence?
(...)
> But because of the operator precedence in Ruby you need to wrap every comparison in parentheses, not very pretty.

I think the problem would the same here. Of course, to know D operator precedence, you have to dig into the grammar, since there is no handy table to give you that info :)

On 10/30/2012 04:47 PM, Philippe Sigaud wrote:
> On Tue, Oct 30, 2012 at 3:44 PM, Jacob Carlborg <doob@me.com> wrote:
>
>> How does that work with operator precedence?
> (...)
>> But because of the operator precedence in Ruby you need to wrap every
>> comparison in parentheses, not very pretty.
>
> I think the problem would the same here. Of course, to know D operator
> precedence, you have to dig into the grammar, since there is no handy
> table to give you that info :)
>

From higher to lower, where relational ops are unordered with respect to bitwise ops (this is the reason comparisons would have to be wrapped in parentheses in D as well):

!
=> (not a real operator, occurs twice this is binding power to the left)
. ++ -- ( [
^^ (right-associative)
& ++ -- * - + ! ~ (prefix)
* / %
+ - ~
<< >> >>>
== != > < >= <= !> !< !>= !<= <> !<> <>= !<>= in !in is !is
&
^
|
&&
||
? (right-associative)
/= &= |= -= += <<= >>= >>>= = *= %= ^= ^^= ~= (right-associative)
=> (not a real operator, occurs twice, this is binding power to the right)
,
.. (not a real operator)

Timon:

> From higher to lower, where relational ops are unordered with respect to bitwise ops (this is the reason comparisons would have to be wrapped in parentheses in D as well):
>
> !
> => (not a real operator, occurs twice this is binding power to the left)
> . ++ -- ( [
> ^^ (right-associative)
> & ++ -- * - + ! ~ (prefix)
> * / %
> + - ~
> << >> >>>
> == != > < >= <= !> !< !>= !<= <> !<> <>= !<>= in !in is !is
> &
> ^
> |
> &&
> ||
> ? (right-associative)
> /= &= |= -= += <<= >>= >>>= = *= %= ^= ^^= ~= (right-associative)
> => (not a real operator, occurs twice, this is binding power to the right)
> ,
> .. (not a real operator)

Thanks a lot Timon!

=> is indeed a strange beast.
Any possibility to put that on a wiki page or the dlang.org on
operator overloading?