View mode: basic / threaded / horizontal-split · Log in · Help
October 29, 2012
Re: Abstract Database Interface
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
October 30, 2012
Re: Abstract Database Interface
>
> 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. :)
October 30, 2012
Re: Abstract Database Interface
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
October 30, 2012
Re: Abstract Database Interface
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 !.
October 30, 2012
Re: Abstract Database Interface
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
October 30, 2012
Re: Abstract Database Interface
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
October 30, 2012
Re: Abstract Database Interface
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
October 30, 2012
Re: Abstract Database Interface
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 :)
October 30, 2012
Re: Abstract Database Interface
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)
October 31, 2012
Re: Abstract Database Interface
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?
1 2 3
Top | Discussion index | About this forum | D home