March 19, 2012
On Mon, 19 Mar 2012 18:28:00 +0100, Simen Kjærås <simen.kjaras@gmail.com> wrote:

> On Mon, 19 Mar 2012 09:29:34 +0100, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> The current limitations make it impossible to define (for example) a floating point type with NaN that behaves like built-in float/double/real.
>
> As it turns out, this is possible. opCmp can return a float, and
> things work just fine (!<, !>=, etc). The problem appears with
> opEquals.
>
> This is the generated assembly:
>
> fldz
> fucompp
> fnstsw   ax
> sahf
> jne      <somewhere>
>
> So it compares the result to 0.0, copies status flags to the CPU,
> then checks if any of the flags are set. If the returned value *is*
> equal to 0.0, the C3 flag is set. The result is that the jump is
> taken only when the returned value is *less* than 0.0. I have a
> feeling this is wrong. Should I file this in BugZilla?

I went ahead and filed it:
http://d.puremagic.com/issues/show_bug.cgi?id=7734
March 21, 2012
On 19/03/12 01:54, Brian Palmer wrote:
> I'm working on a DSL for generating SQL queries, based loosely on
> Python's SQLAlchemy and Ruby's Sequel. One nice thing about the DSL is
> the compact syntax for specifying WHERE clauses. With some fiddling, I
> got it working for opEquals, a simplified example:
>
> foreach(network; db["networks"].each) {
> writefln("network: %s", network.name);
> foreach(host; db["hosts"].where(db.c.id == network.id)) {
> writefln("\thost: %s", host.address);
> }
> }
>
> This works because db.c.id returns a struct which defines an opEquals
> which returns a "Filter" struct, rather than an int. I'm not positive
> that it should really be allowed by the compiler, but it works:
>
> struct Filter { ... }
> struct Column {
> Filter opEquals(T)(T rhs) { ... }
> }
>
> Then the .where call takes a filter, and uses it to output a snippet of
> sql like "id = 5"
>
> However, this won't work for comparison operators like < and >, which
> all map to opCmp, or for != (since that's rewritten to !(a == b))
>
> I guess I have two questions, one, am I going to shoot myself in the
> foot by going down this path, because it only happens to work due to the
> compiler being too lax? And is there interest in extending D to allow
> the rest of the operators to return non-boolean results? I'm thinking
> something like falling back to opBinary!("<"), etc, if opCmp isn't
> defined for a struct.

I don't think this is EVER what you really want.
I believe that if you think you want this feature, 100% of the time, what you really want is a syntax tree of the entire expression. That is, either you want ">" to be a comparison, and "+" to be an addition, OR you want a syntax tree.



March 21, 2012
On Wednesday, 21 March 2012 at 11:05:41 UTC, Don Clugston wrote:

> I don't think this is EVER what you really want.
> I believe that if you think you want this feature, 100% of the time, what you really want is a syntax tree of the entire expression. That is, either you want ">" to be a comparison, and "+" to be an addition, OR you want a syntax tree.

Well yes, the whole point is to build up a syntax tree that can be manipulated before being outputted as a raw sql string. The operator overloading is a convenient way to do that, that has turned out to be intuitive and easy for developers to use in many other DSLs. To say that's not EVER what you really want seems a bit silly, considering all the libraries in other languages that utilize this technique.

That said, if this isn't the D way, it's not the D way, I'm certainly not going to try and shoe-horn it in based on undefined behavior or something.
March 21, 2012
On Wed, Mar 21, 2012 at 03:29:21PM +0100, Brian Palmer wrote:
> On Wednesday, 21 March 2012 at 11:05:41 UTC, Don Clugston wrote:
> 
> >I don't think this is EVER what you really want.
> >I believe that if you think you want this feature, 100% of the
> >time, what you really want is a syntax tree of the entire
> >expression. That is, either you want ">" to be a comparison, and
> >"+" to be an addition, OR you want a syntax tree.
> 
> Well yes, the whole point is to build up a syntax tree that can be manipulated before being outputted as a raw sql string. The operator overloading is a convenient way to do that, that has turned out to be intuitive and easy for developers to use in many other DSLs. To say that's not EVER what you really want seems a bit silly, considering all the libraries in other languages that utilize this technique.
> 
> That said, if this isn't the D way, it's not the D way, I'm certainly not going to try and shoe-horn it in based on undefined behavior or something.

The "D way" is to use strings for DSELs which get evaluated at compile-time, or a custom set of methods that you can build expressions out of. Operator overloading really should be limited to arithmetic types (for numerical classes) and built-in operations like array lookups and stuff.

Trying to shoehorn language-level operators to do something they weren't intended to do only leads to problems. (C++'s overloading of << and >> for I/O is a very bad design decision IMO.)


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl
March 21, 2012
On 2012-03-21 17:44, H. S. Teoh wrote:

> The "D way" is to use strings for DSELs which get evaluated at
> compile-time, or a custom set of methods that you can build expressions
> out of. Operator overloading really should be limited to arithmetic
> types (for numerical classes) and built-in operations like array lookups
> and stuff.
>
> Trying to shoehorn language-level operators to do something they weren't
> intended to do only leads to problems. (C++'s overloading of<<  and>>
> for I/O is a very bad design decision IMO.)

"find", "map" and similar functions can be used on arrays. What's wrong in being able to use the same syntax for accessing a database. I think the following would be a great syntax:

Person.where(x => x.name == "John");

Where "Person" is a class connected to a database table.

-- 
/Jacob Carlborg
March 22, 2012
On 21/03/12 21:53, Jacob Carlborg wrote:
> On 2012-03-21 17:44, H. S. Teoh wrote:
>
>> The "D way" is to use strings for DSELs which get evaluated at
>> compile-time, or a custom set of methods that you can build expressions
>> out of. Operator overloading really should be limited to arithmetic
>> types (for numerical classes) and built-in operations like array lookups
>> and stuff.
>>
>> Trying to shoehorn language-level operators to do something they weren't
>> intended to do only leads to problems. (C++'s overloading of<< and>>
>> for I/O is a very bad design decision IMO.)
>
> "find", "map" and similar functions can be used on arrays. What's wrong
> in being able to use the same syntax for accessing a database. I think
> the following would be a great syntax:
>
> Person.where(x => x.name == "John");
>
> Where "Person" is a class connected to a database table.
>

Indeed, it may be possible to use a new-style delegate literal instead of a string, for defining your DSL.
My point was that we don't need to be able to return arbitrary types from operators. Instead, we might need some syntax sugar or library support for getting syntax trees from expressions.
March 22, 2012
On Thursday, 22 March 2012 at 10:06:46 UTC, Don Clugston wrote:
> Indeed, it may be possible to use a new-style delegate literal instead of a string, for defining your DSL.
> My point was that we don't need to be able to return arbitrary types from operators. Instead, we might need some syntax sugar or library support for getting syntax trees from expressions.

And how exactly do you plan to implement _library_ support for that in the case of expressions containing comparison or equality operators?

David
March 23, 2012
"David Nadlinger" <see@klickverbot.at> wrote in message news:ajuozpunkzfawcapczcg@forum.dlang.org...
>
> And how exactly do you plan to implement _library_ support for that in the case of expressions containing comparison or equality operators?
>
> David

With a D parser in phobos.


1 2
Next ›   Last »