www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why D is annoying =P

reply "Mehrdad" <wfunction hotmail.com> writes:
I couldn't find a better title, sorry.


But yeah, I've spent too many hours on hunting down problems like 
these...


Could someone explain what's going on? Thanks!

import std.stdio;
struct S { int[int] aa; }
void main()
{
	writeln(  [1: 2]  ==   [1: 2] );  // true
	writeln(S([1: 2]) == S([1: 2]));  // false
}

(I'm on Windows DMD v2.060.)
Oct 24 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/24/2012 09:17 PM, Mehrdad wrote:
 I couldn't find a better title, sorry.


 But yeah, I've spent too many hours on hunting down problems like these...


 Could someone explain what's going on? Thanks!

 import std.stdio;
 struct S { int[int] aa; }
 void main()
 {
      writeln(  [1: 2]  ==   [1: 2] );  // true
      writeln(S([1: 2]) == S([1: 2]));  // false
 }

 (I'm on Windows DMD v2.060.)

http://d.puremagic.com/issues/show_bug.cgi?id=3789
Oct 24 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/24/12, Mehrdad <wfunction hotmail.com> wrote:
 Could someone explain what's going on? Thanks!

Struct fields are compared by address by default if no opEquals is defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 19:25:47 UTC, Timon Gehr wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=3789

Ouch, bug since 2010... (Thanks for the link.)
Oct 24 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/24/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 10/24/12, Mehrdad <wfunction hotmail.com> wrote:
 Could someone explain what's going on? Thanks!

Struct fields are compared by address by default if no opEquals is defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789

Well I mean for reference types. Or something like that. To put it bluntly: It's brokeeen.
Oct 24 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-24 21:37, Mehrdad wrote:

 I don't know what to expect code like this to do (unlike in C++, where
 everything is clearly defined in the specs), and when it seems to do
 what I want, it really turns out to be a bug in the library that it
 seemed to work in the first place. :(

Everything in C++ is specified as undefined behavior :) -- /Jacob Carlborg
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 19:28:36 UTC, Andrej Mitrovic 
wrote:
 On 10/24/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 10/24/12, Mehrdad <wfunction hotmail.com> wrote:
 Could someone explain what's going on? Thanks!

Struct fields are compared by address by default if no opEquals is defined. http://d.puremagic.com/issues/show_bug.cgi?id=3789

Well I mean for reference types. Or something like that. To put it bluntly: It's brokeeen.

Yeah, and my attempts to get around it don't seem to help: auto a = [1:1], b = [1:1]; writeln(a == b); // true writeln(a in [a:0]); // null
Oct 24 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 09:17:09PM +0200, Mehrdad wrote:
[...]
 Could someone explain what's going on? Thanks!
 
 import std.stdio;
 struct S { int[int] aa; }
 void main()
 {
 	writeln(  [1: 2]  ==   [1: 2] );  // true
 	writeln(S([1: 2]) == S([1: 2]));  // false
 }

I don't know if there is any struct-specific problem here, but AA comparison right now is horribly horribly broken (search on the bug tracker for "AA" and you'll see a bunch of issues on that end). You're incredibly lucky that two AA literals actually compared equal. In some cases, not even that is guaranteed. I've tried to clean up the AA code but it's a tangled messy ugly labyrinth with fragile hacks sprinkled in, and didn't get to the point where it's ready to commit. One major obstacle is that parts of it are implemented in compiler hacks, and part of it is schizophrenically duplicated in object_.d, not necessarily consistently, and it's just Not Nice in general. That it works at all is reason enough to be thankful. I don't expect things to be pretty once you start poking into the intricacies of AA's, sad to say. T -- People tell me I'm stubborn, but I refuse to accept it!
Oct 24 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/24/2012 10:16 PM, Mehrdad wrote:
 ...

 Maybe you can fill in the blanks?

import std.stdio; struct Set(T){ int[T] dict; hash_t toHash() const{ typeof(return) r = 0; foreach(item; this.dict.keys){ r+=typeid(T).getHash(&item); } return r; } }
Oct 24 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/24/2012 09:41 PM, Mehrdad wrote:
 ...
 So you can't really write a real program in D, to put it blunty.

Yes I can.
Oct 24 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/25/2012 12:22 AM, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 22:00:27 UTC, Timon Gehr wrote:
 On 10/24/2012 09:41 PM, Mehrdad wrote:
 ...
 So you can't really write a real program in D, to put it blunty.

Yes I can.

So you made your own AA and Set implementations instead of trying to use Photos?

I have written a custom hash map.
 Or did you never run into these problems?

It is actually hard to miss them.
Oct 24 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/24/12 8:53 PM, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 21:55:53 UTC, Era Scarecrow wrote:
 On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
 So you can't really write a real program in D, to put it blunty.

So should I drop a project I'm working on and go to C++? That isn't something I look forward to doing...

Well if it's been working for you then there's obviously no reason to. :) I couldn't say the same thing, though.

OK let's stop this. There's a bug that needs fixing, is all. Andrei
Oct 24 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 25/10/2012 03:35, Jonathan M Davis a écrit :
 On Wednesday, October 24, 2012 21:01:11 Andrei Alexandrescu wrote:
 OK let's stop this. There's a bug that needs fixing, is all.

And as bad as things may be now, they're _way_ better than they were a couple of years ago (or even a year ago). The situation isn't perfect, but it's constantly improving. It's becoming rarer and rarer for programmers to run into compiler bugs.

Is this a joke ? That is true that many bug get solved, but I encounter compiler bugs almost on a daily basis, and a lot of workaround are present in my codebase. I'm ready to heard that I run into more bugs due to my coding style or whatever, but I have hard time to understand how running into compiler bugs can be rarer and rarer. You can actually write plenty of programmers now without
 running into any, whereas before, you'd run into them all the time.

 - Jonathan M Davis

Oct 26 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-24 21:41, Mehrdad wrote:

 Yeah, the trouble is, none of the set-based data types (including maps)
 in D seem to be working...

 - AAs are broken
 - AssociativeArray is the same as above, I think?
 - RedBlackTree is useless (how do I keep a "set of sets"?)
 etc.


 So you can't really write a real program in D, to put it blunty.

I haven't read the rest of thread yet but if you're not happy the the collections in D or Phobos, Tango has a collection package and Steven Schveighoffer has a collection library (don't remember where though). -- /Jacob Carlborg
Oct 24 2012
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 10/24/2012 01:16 PM, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 20:03:44 UTC, H. S. Teoh wrote:
 What's wrong with RedBlackTree? You can just do something like:

     RedBlackTree!(RedBlackTree!MySet) setOfSets;

The last time I checked two RedBlackTrees for equality, they seemed to have reference semantics...

Dang. import std.container; import std.stdio; void main() { auto a = make!(RedBlackTree!int)(1,2,3,4); auto b = make!(RedBlackTree!int)(1,2,3,4); writeln(a == b); } prints false Explanation: RedBlackTree doesn't override opEquals. Either file an enhancement request or use equal(a[], b[]), depending on whether opEquals *should* have reference semantics. Actually, it shouldn't, since that would differ from array/string opEquals semantics. SList works Array works Oop. DList goes into infinite loop. Dibs on this bug report.
Oct 25 2012
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 10/25/2012 09:19 PM, H. S. Teoh wrote:
 Hmph. This is what I don't like about the built-in ==. Its semantics are
 inconsistent once you leave the realm of ints and floats and other
 numerical types. I think this one is worthy of a bug report.

Well, if nobody else is going to take it http://d.puremagic.com/issues/show_bug.cgi?id=8896
Oct 25 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 19:32:08 UTC, Mehrdad wrote:
 Yeah, and my attempts to get around it don't seem to help:

 	auto a = [1:1], b = [1:1];
 	writeln(a == b);       // true
 	writeln(a in [a:0]);   // null

Harsh (but true, and perhaps useful) feedback... I feel like this is a *perfect* example of the kinds of things that turn people off of D. I don't know what to expect code like this to do (unlike in C++, where everything is clearly defined in the specs), and when it seems to do what I want, it really turns out to be a bug in the library that it seemed to work in the first place. :(
Oct 24 2012
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 19:34:15 UTC, H. S. Teoh wrote:
 I don't know if there is any struct-specific problem here, but 
 AA comparison right now is horribly horribly broken (search on 
 the bug tracker for "AA" and you'll see a bunch of issues on 
 that end). You're incredibly lucky that two AA literals 
 actually compared equal. In some cases, not even that is 
 guaranteed.

Yeah, I was a little aware that AAs were semi-broken, but I thought, hey, if it seems to work then it obviously works. Turns out that wasn't so true. :\
 I've tried to clean up the AA code but it's a tangled messy 
 ugly labyrinth with fragile hacks sprinkled in, and didn't get 
 to the point where it's ready to commit. One major obstacle is 
 that parts of it are implemented in compiler hacks, and part of 
 it is schizophrenically duplicated in object_.d, not 
 necessarily consistently, and it's just Not Nice in general. 
 That it works at all is reason enough to be thankful. I don't 
 expect things to be pretty once you start poking into the 
 intricacies of AA's, sad to say.

Yeah, the trouble is, none of the set-based data types (including maps) in D seem to be working... - AAs are broken - AssociativeArray is the same as above, I think? - RedBlackTree is useless (how do I keep a "set of sets"?) etc. So you can't really write a real program in D, to put it blunty.
Oct 24 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 25, 2012 at 05:34:05AM +0200, Mehrdad wrote:
 Funny, I was actually building a (GLR) parser, too.
 
 Keeping track of duplicate item sets was what tripped me up.

Oh. You should've said so earlier -- for such specific applications, you don't _need_ a fully generalized solution to the AA hash problem. You can just implement your own .toHash methods on the structs/objects your parser uses, and be done with it. No need to try to accomodate every single type D has or can have -- that's the kind of thing Phobos developers have to worry about, not people who have a specific application in mind. I've learnt from hard experience that premature generalization is just as evil as premature optimization. (Believe me, I'm a sucker for completely general solutions too -- I like killing ants with nuclear warheads, proverbially speaking, just for the feeling of confidence that that it would've also worked in the hypothetical scenario of levelling an entire city.) You usually end up completely frustrated that the system/language you're using just doesn't have that one last bit of homogeneity for your generalization to fully work, and eventually the project never gets off the ground. But in many cases, I've learned, this is all needless pain. Write the case-specific code first, and then refactor and generalize it afterwards. Works much better, I find, and you have a tangible product to speak of from the get-go, instead of spending countless hours writing a generic framework that eventually never gets used. Plus, when you actually have a *working* codebase, exactly which generalizations will work, and which are just castles in the air, tend to be a lot more obvious than when you're just sketching the product on the drawing board. Just my slightly more than $0.02. :) T -- English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan
Oct 24 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Haha thanks a bunch for the advice. :) I was actually intending 
it to be a quick hack, not a highly-generalized thing.

So I thought, hey, I'll just use a
Tuple!(string, q{symbol}, size_t, q{iRule}, size_t, q{iSymbol})
to denote an "LR Item".



So an "item set" became RedBlackTree!(Tuple!(...)), but that 
didn't work because of the reference semantics.

So I tried int[Tuple!(...)], and hence the story.



(I actually even scrapped the idea of using a 'set' and just used 
an array.

Screw the O(n) performance.

But one of my goals was getting the code to be concise (the idea 
was to use CTFE + mixins/templates to generate some optimized 
code with switch statements for the parser), but sprinkling it 
with all the sort()s and all the code required to switch from 
hashtables to arrays just made it too ugly/indecipherable for me 
to continue working on it.)

etc.

But yeah, thanks for the advice, I'll keep it in mind. :)
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
 So you can't really write a real program in D, to put it 
 bluntly.

Case in point: there's no way to tell an arbitrary object/struct to give you its hash code.
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 09:41:41PM +0200, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 19:34:15 UTC, H. S. Teoh wrote:
I don't know if there is any struct-specific problem here, but AA
comparison right now is horribly horribly broken (search on the
bug tracker for "AA" and you'll see a bunch of issues on that
end). You're incredibly lucky that two AA literals actually
compared equal. In some cases, not even that is guaranteed.

Yeah, I was a little aware that AAs were semi-broken, but I thought, hey, if it seems to work then it obviously works. Turns out that wasn't so true. :\

The AA implementation badly needs to be revamped. But the problem is that it's non-trivial, may break existing code, etc.. I do have a (semi) working version of a prospective AA replacement, though: https://github.com/quickfur/New-AA-implementation You might be able to make use of it if you're willing to live with broken IFTI (which is no big deal if you just explicitly type what you instantiate the AA with).
I've tried to clean up the AA code but it's a tangled messy ugly
labyrinth with fragile hacks sprinkled in, and didn't get to the
point where it's ready to commit. One major obstacle is that parts
of it are implemented in compiler hacks, and part of it is
schizophrenically duplicated in object_.d, not necessarily
consistently, and it's just Not Nice in general. That it works at
all is reason enough to be thankful. I don't expect things to be
pretty once you start poking into the intricacies of AA's, sad to
say.

Yeah, the trouble is, none of the set-based data types (including maps) in D seem to be working... - AAs are broken - AssociativeArray is the same as above, I think?

Yes it's the same. It's not meant to be used directly by user code, though. The two are supposed to be the same.
 - RedBlackTree is useless (how do I keep a "set of sets"?)

What's wrong with RedBlackTree? You can just do something like: RedBlackTree!(RedBlackTree!MySet) setOfSets; [...]
 So you can't really write a real program in D, to put it blunty.

That's a bit harsh. It's not hard to write your own hash implementation in D, given the expressiveness of its templates and compile-time features. The bugginess of the built-in AA is lamentable, definitely, but it doesn't *prevent* you from writing your own data structures. All programmers worth their salt should be able to roll their own where the current implementation is inadequate, anyway. ;-) In any case, as they say in the open source community, patches are always welcome. Plus, you *can* use AA's for all sorts of stuff in general, if you just avoid some of the most glaring bugs. It only takes 15 minutes to write your own opEquals() in a struct that wraps around an AA, and it's equally fast to parametrize that struct to take arbitrary types, and provide wrapper functions that work around the current bugs. None of the current issues are showstoppers, as annoying as they may be. T -- Do not reason with the unreasonable; you lose by definition.
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 09:50:18PM +0200, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
So you can't really write a real program in D, to put it bluntly.

Case in point: there's no way to tell an arbitrary object/struct to give you its hash code.

Huh? All objects implement toHash(). If the default toHash() doesn't satisfy you, override it with your own. You can just use rt.util.hash.hashOf for structs. Use UFCS to make it callable as toHash(). Implement your own toHash() where hashOf isn't good enough. Problem solved. T -- Once bitten, twice cry...
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:04:24 UTC, Jacob Carlborg 
wrote:
 On 2012-10-24 21:37, Mehrdad wrote:

 I don't know what to expect code like this to do (unlike in 
 C++, where everything is clearly defined in the specs), and 
 when it seems to do what I want, it really turns out to be a 
 bug in the library that it seemed to work in the first place. 
 :(

Everything in C++ is specified as undefined behavior :)

lol. I meant more like, it's clear in C++ which operations need to be implemented in order for an object to be hashable, for instance. I can't figure out how hashing works in D at all.
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:07:49 UTC, H. S. Teoh wrote:
 On Wed, Oct 24, 2012 at 09:50:18PM +0200, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
So you can't really write a real program in D, to put it 
bluntly.

Case in point: there's no way to tell an arbitrary object/struct to give you its hash code.

Huh? All objects implement toHash().

Not Tuples, apparently. (I didn't mean Object, I mean "object" in the general sense.)
 You can just use rt.util.hash.hashOf for structs.

Will try, thanks for the pointer.
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 10:09:36PM +0200, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 20:07:49 UTC, H. S. Teoh wrote:
On Wed, Oct 24, 2012 at 09:50:18PM +0200, Mehrdad wrote:
On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
So you can't really write a real program in D, to put it
bluntly.

Case in point: there's no way to tell an arbitrary object/struct to give you its hash code.

Huh? All objects implement toHash().

Not Tuples, apparently. (I didn't mean Object, I mean "object" in the general sense.)

Well, Object implements toHash(). Other things don't, but with UFCS you can endow them with toHash(). :)
You can just use rt.util.hash.hashOf for structs.

Will try, thanks for the pointer.

hashOf works for pretty much anything (it's just a byte-based algo). So it's not just structs, you can pass anything to it. Using UFCS to map toHash() to hashOf will give you toHash() for literally everything, which is apparently what you want (though I question the wisdom of wanting a hash value of *everything*, including objects representing network resources, the OS, etc., but hey, you can do it if you *really* want to). T -- It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:03:44 UTC, H. S. Teoh wrote:
 What's wrong with RedBlackTree? You can just do something like:

 	RedBlackTree!(RedBlackTree!MySet) setOfSets;

The last time I checked two RedBlackTrees for equality, they seemed to have reference semantics...
 [...]
 So you can't really write a real program in D, to put it 
 blunty.

That's a bit harsh.

Sorry, just saying what I experienced :(
 It's not hard to write your own hash implementation in D

I beg to differ, see below
 given the expressiveness of its templates and compile-time 
 features. The bugginess of the built-in AA is lamentable, 
 definitely, but it doesn't *prevent* you from writing your own 
 data structures.

It does. There's simply no mechanism to hash an arbitrary thing in D. (hashOf, which Andrej just mentioned, is an internal thing, right? aka a hack, which I was not aware of)
 All programmers worth their salt should be able to roll their 
 own where the current implementation is inadequate, anyway. ;-)

Well, there's different issues involved... - Can I? Yes. - Will I? No, it takes more time than it's worth
 In any case,  as they say in the open source community, patches 
 are always welcome.

Yeah, it's just that I can't figure out even the basics of hashing in D (above), so I can't really patch something because then it'll turn out to be working in a different way than I expect.
 It only takes 15 minutes to write your own opEquals() in a 
 struct that wraps around an AA

I've spent longer than that right now and still haven't been able to (but I haven't tried the hashOf hack yet). Maybe you can fill in the blanks? struct Set(T) { int[T] dict; hash_t toHash() const { typeof(return) r = 0; foreach (item; this.dict.keys) { ??? // what should be here? } return r; } }
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:15:07 UTC, H. S. Teoh wrote:
 hashOf works for pretty much anything (it's just a byte-based 
 algo).

Byte-based? what about Set!(Tuple!(int, string)) s; s[tuple(1, "hi")] = 1; writeln(tuple(1, "hi".dup) in s); // null or not?
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:18:07 UTC, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 20:15:07 UTC, H. S. Teoh wrote:
 hashOf works for pretty much anything (it's just a byte-based 
 algo).

Byte-based? what about Set!(Tuple!(int, string)) s; s[tuple(1, "hi")] = 1; writeln(tuple(1, "hi".dup) in s); // null or not?

my bad, I mixed up AA and sets. That was supposed to insert the item, not map it to 1. Would it work?
Oct 24 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2012 12:17 PM, Mehrdad wrote:
 I couldn't find a better title, sorry.


 But yeah, I've spent too many hours on hunting down problems like these...


 Could someone explain what's going on? Thanks!

 import std.stdio;
 struct S { int[int] aa; }
 void main()
 {
      writeln(  [1: 2]  ==   [1: 2] );  // true
      writeln(S([1: 2]) == S([1: 2]));  // false
 }

 (I'm on Windows DMD v2.060.)

The compare for associative arrays is to compare the members. The default compare for structs is a bit compare of the contents.
Oct 24 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 25/10/2012 04:12, Jonathan M Davis a écrit :
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==. - Jonathan M Davis

That will broke code. But That is the way to go IMO. D needs to evolve to make things more consistent in general. Still not doable without a proper versionning scheme.
Oct 26 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-26 19:46, deadalnix wrote:

 That will broke code.

 But That is the way to go IMO. D needs to evolve to make things more
 consistent in general.

 Still not doable without a proper versionning scheme.

Fixing bugs can always break code and I don't think any version scheme can help here. But what a version scheme can help with is when changing the API. When you add a new function, that won't break any code. Removing a function will break code. -- /Jacob Carlborg
Oct 28 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:32:00 UTC, Walter Bright 
wrote:
 The default compare for structs is a bit compare of the 
 contents.

Thanks for the reply. And hmm, that should be changed IMO. ;) Bitwise comparison is nearly useless.
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 10:16:27PM +0200, Mehrdad wrote:
[...]
 struct Set(T)
 {
 	int[T] dict;
 	hash_t toHash() const
 	{
 		typeof(return) r = 0;
 		foreach (item; this.dict.keys)
 		{
 			???       // what should be here?
 		}
 		return r;
 	}
 }

Try this: hash_t toHash() const { hash_t h = 0; foreach (item; this.dict.keys) { // We use a commutative operation here (+) so // that the order of keys don't matter. h += hashOf(&item, item.sizeof); } return h; } T -- What do you get if you drop a piano down a mineshaft? A flat minor.
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:37:08 UTC, H. S. Teoh wrote:
 On Wed, Oct 24, 2012 at 10:16:27PM +0200, Mehrdad wrote:
 [...]
 struct Set(T)
 {
 	int[T] dict;
 	hash_t toHash() const
 	{
 		typeof(return) r = 0;
 		foreach (item; this.dict.keys)
 		{
 			???       // what should be here?
 		}
 		return r;
 	}
 }

Try this: hash_t toHash() const { hash_t h = 0; foreach (item; this.dict.keys) { // We use a commutative operation here (+) so // that the order of keys don't matter. h += hashOf(&item, item.sizeof); } return h; } T

Wouldn't that do a bitwise comparison?
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:38:08 UTC, Mehrdad wrote:
 Wouldn't that do a bitwise comparison?

sorry, I mean bitwise _hash_
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Is there any reason why we don't have something like this in 
Phobos?



hash_t toHash(T)(in T t) if (isIntegral!(T) || isSomeChar!(T))
{
	return t;
}

hash_t toHash(T)(in T[] t)
{
	typeof(return) h = 0;
	foreach (item; t)
	{ h = h * 37 + item.toHash(); }
	return h;
}

hash_t toHash(T)(in T t) if (!isIntegral!(T) && !isSomeChar!(T) 
&& !isArray!(T))
{
	typeof(return) h = 0;
	foreach (ref a; t.tupleof)
	{ h = h * 37 + a.toHash(); }
	return h;
}

hash_t toHash(T...)(in Tuple!(T) t)
{
	typeof(return) h = 0;
	foreach (item; t)
	{ h = h * 37 + item.toHash(); }
	return h;
}
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 10:38:07PM +0200, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 20:37:08 UTC, H. S. Teoh wrote:
On Wed, Oct 24, 2012 at 10:16:27PM +0200, Mehrdad wrote:
[...]
struct Set(T)
{
	int[T] dict;
	hash_t toHash() const
	{
		typeof(return) r = 0;
		foreach (item; this.dict.keys)
		{
			???       // what should be here?
		}
		return r;
	}
}

Try this: hash_t toHash() const { hash_t h = 0; foreach (item; this.dict.keys) { // We use a commutative operation here (+) so // that the order of keys don't matter. h += hashOf(&item, item.sizeof); } return h; } T

Wouldn't that do a bitwise comparison?

Umm, the idea of a hash is to *quickly* compute a value that's (mostly) unique for a given object. In most cases, the bit representation is good enough. If you want a thorough recursive comparison of all subobjects, you should overload opEquals and use that instead. Or use compile-time reflection to iterate over every member of the given object and recursively iterate and hash them. Though I fail to see the point of it, since it defeats the purpose of a hash in the first place - you might as well just do the usual recursive compare instead. T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 20:47:30 UTC, H. S. Teoh wrote:
 Umm, the idea of a hash is to *quickly* compute a value that's 
 (mostly) unique for a given object. In most cases, the bit 
 representation is good enough.

I don't understand what you're saying. hash(tuple("foo".dup)) MUST be equal to hash(tuple("foo".dup")). Bitwise hashing makes no sense whatsoever.
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Better example:



private import std.traits, std.typecons, std.typetuple;

hash_t toHash(T)(in T t)
	if (isIntegral!(T) || isSomeChar!(T))
{ return t; }

hash_t toHash(T)(in T[] t)
{
	typeof(return) h = 0;
	foreach (item; t)
	{ h = (h * 37) ^ item.toHash(); }
	return h;
}

hash_t toHash(V, K)(in V[K] t)
{
	typeof(return) h = 0;
	foreach (k, v; t)
	{ h ^= k.toHash(); }
	return h;
}

hash_t toHash(T)(in T t)
	if (!isIntegral!(T) &&
	    !isSomeChar!(T) &&
	    !isArray!(T) &&
             !isAssociativeArray!(T))
{
	typeof(return) h = 0;
	foreach (ref a; t.tupleof)
	{ h = (h * 37) ^ a.toHash(); }
	return h;
}

void main()
{
	import std.stdio;
	writeln(tuple("hi", [[1: 2].keys.dup], [1: 2, 8: 4]).toHash());
	writeln(tuple("hi", [[1: 2].keys.dup], [1: 2, 8: 4]).toHash());  
// same thing as above
}





We really _need_ something like this in Phobos IMHO.
Oct 24 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
 So you can't really write a real program in D, to put it blunty.

So should I drop a project I'm working on and go to C++? That isn't something I look forward to doing...
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 22:00:27 UTC, Timon Gehr wrote:
 On 10/24/2012 09:41 PM, Mehrdad wrote:
 ...
 So you can't really write a real program in D, to put it 
 blunty.

Yes I can.

So you made your own AA and Set implementations instead of trying to use Photos? Or did you never run into these problems?
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 21:55:11 UTC, Timon Gehr wrote:
 On 10/24/2012 10:16 PM, Mehrdad wrote:
 ...

 Maybe you can fill in the blanks?

import std.stdio; struct Set(T){ int[T] dict; hash_t toHash() const{ typeof(return) r = 0; foreach(item; this.dict.keys){ r+=typeid(T).getHash(&item); } return r; } }

I'm on my phone so I can't test it right now, but I'm wondering how that would possibly work correctly for Tuples and such?
Oct 24 2012
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 24 October 2012 at 21:55:53 UTC, Era Scarecrow 
wrote:
 On Wednesday, 24 October 2012 at 19:41:42 UTC, Mehrdad wrote:
 So you can't really write a real program in D, to put it 
 blunty.

So should I drop a project I'm working on and go to C++? That isn't something I look forward to doing...

Well if it's been working for you then there's obviously no reason to. :) I couldn't say the same thing, though.
Oct 24 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 25, 2012 at 06:21:02AM +0200, Mehrdad wrote:
 Haha thanks a bunch for the advice. :) I was actually intending it
 to be a quick hack, not a highly-generalized thing.
 
 So I thought, hey, I'll just use a
 Tuple!(string, q{symbol}, size_t, q{iRule}, size_t, q{iSymbol})
 to denote an "LR Item".

Hmm, why are you using Tuple? Shouldn't you be using a struct? T -- People tell me I'm stubborn, but I refuse to accept it!
Oct 24 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 25 October 2012 at 04:39:28 UTC, H. S. Teoh wrote:
 On Thu, Oct 25, 2012 at 06:21:02AM +0200, Mehrdad wrote:
 Haha thanks a bunch for the advice. :) I was actually 
 intending it
 to be a quick hack, not a highly-generalized thing.
 
 So I thought, hey, I'll just use a
 Tuple!(string, q{symbol}, size_t, q{iRule}, size_t, q{iSymbol})
 to denote an "LR Item".

Hmm, why are you using Tuple? Shouldn't you be using a struct? T

Hmm, why would I prefer a struct over a Tuple? I see it as, like, coordinates -- the index of the symbol in the production, and the index of the production for a given nonterminal symbol. So tuple(x, y, z) kinda made sense. Especially since I was going back/forth between D & Python.
Oct 24 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 25 October 2012 at 00:53:31 UTC, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 21:55:53 UTC, Era Scarecrow
 So should I drop a project I'm working on and go to C++? That 
 isn't something I look forward to doing...

Well if it's been working for you then there's obviously no reason to. :) I couldn't say the same thing, though.

You can always work around what does and doesn't work; Although preferably you shouldn't have to. I can only think that the best way to support the D language is simply to use it. If there's several programs that really get attention that shows the flexibility and use of D then it's more likely to be used. My biggest obstacle(s) right now is time & memory. With new issues coming up it makes you think in different directions, which all makes sense once you look for them.
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 25 October 2012 at 01:01:10 UTC, Andrei Alexandrescu 
wrote:
 OK let's stop this. There's a bug that needs fixing, is all.

 Andrei

Sorry, yeah. It was just that I came across it so much that I wanted to put it on the radar here, to let you guys know what sorts of problems you'd run into when you try using D. It was meant to be honest feedback, that's all... I realize it was negative hopefully it was at least constructive. Any opinions on my proposed "fixed" version, which used .tupleof?
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 25 October 2012 at 01:36:00 UTC, Era Scarecrow wrote:
 On Thursday, 25 October 2012 at 00:53:31 UTC, Mehrdad wrote:
 On Wednesday, 24 October 2012 at 21:55:53 UTC, Era Scarecrow
 So should I drop a project I'm working on and go to C++? That 
 isn't something I look forward to doing...

Well if it's been working for you then there's obviously no reason to. :) I couldn't say the same thing, though.

You can always work around what does and doesn't work; Although preferably you shouldn't have to.

Well I mean, yeah, you can obviously implement your own data structures, and eventually, your own version of Phobos, even. The trouble is, then you're fighting the framework, and nothing integrates with anything else. Some data structure expects a toHash() instance method, another expects .hashOf, another getHash(), another getHashCode(), another might say hashCode(), and yet another might just expect a template specialization, like in C++. So the point is, yes, it's possible. It's not that I can't work around it, but it defeats the whole purpose of switching to D.
Oct 24 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 25 October 2012 at 01:50:05 UTC, Mehrdad wrote:
 Well I mean, yeah, you can obviously implement your own data 
 structures, and eventually, your own version of Phobos, even.

 The trouble is, then you're fighting the framework, and nothing 
 integrates with anything else. Some data structure expects a 
 toHash() instance method, another expects .hashOf, another 
 getHash(), another getHashCode(), another might say hashCode(), 
 and yet another might just expect a template specialization, 
 like in C++.

 So the point is, yes, it's possible. It's not that I can't work 
 around it, but it defeats the whole purpose of switching to D.

I have no intention of writing a different version of phobos or breaking the framework. I'll work within the framework as much as possible; Working around the issues usually ends up force casting something so you can get the job done (but you still need to honor the type's original contract). I'll just hope my data processing won't require anything that's broken or going to be depreciated, I've already dropped using std.stream for ranges instead. Dropping classes in favor of structs.
Oct 24 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==. - Jonathan M Davis
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 25, 2012 at 04:08:21AM +0200, Era Scarecrow wrote:
[...]
 I'll just hope my data processing won't require anything that's
 broken or going to be depreciated, I've already dropped using
 std.stream for ranges instead. Dropping classes in favor of structs.

Huh? Why would you drop classes in favor of structs? They are used for two different purposes. Classes are for when you need polymorphism: inheritance, overloading, interfaces, all the trappings of OO programming. Structs are for when you need value types that doesn't need OO-style manipulations. Not the same thing. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 24, 2012 at 10:12:48PM -0400, Jonathan M Davis wrote:
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==.

The built-in AA's suffer from the same problem. Which is why sometimes, if you use a struct as key, entries cannot be found because the key being looked up is bitwise different from any key in the AA, but they have the same value (e.g., the struct has a reference to two distinct objects that have the same value). T -- Food and laptops don't mix.
Oct 24 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 25 October 2012 at 02:19:39 UTC, H. S. Teoh wrote:

 Huh? Why would you drop classes in favor of structs? They are 
 used for two different purposes. Classes are for when you need 
 polymorphism: inheritance, overloading, interfaces, all the 
 trappings of OO programming. Structs are for when you need 
 value types that doesn't need OO-style manipulations. Not the 
 same thing.

Indeed. Instead of interfaces you'd use templates, OO doesn't change really all that much. There's also large amounts of memory consumption that just isn't needed for data that hasn't and/or isn't going to change. More often I'm thinking structs w/templates are more powerful than classes. I'm experimenting with a polymorphic struct. Run-time price is a couple enum checks if there's multiple functions that might qualify, and slightly different calling for those polymorphic types.
Oct 24 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 24, 2012 21:01:11 Andrei Alexandrescu wrote:
 OK let's stop this. There's a bug that needs fixing, is all.

And as bad as things may be now, they're _way_ better than they were a couple of years ago (or even a year ago). The situation isn't perfect, but it's constantly improving. It's becoming rarer and rarer for programmers to run into compiler bugs. You can actually write plenty of programmers now without running into any, whereas before, you'd run into them all the time. - Jonathan M Davis
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 25 October 2012 at 02:55:20 UTC, Jonathan M Davis 
wrote:
 On Wednesday, October 24, 2012 21:01:11 Andrei Alexandrescu 
 wrote:
 OK let's stop this. There's a bug that needs fixing, is all.

And as bad as things may be now, they're _way_ better than they were a couple of years ago (or even a year ago). The situation isn't perfect, but it's constantly improving. It's becoming rarer and rarer for programmers to run into compiler bugs. You can actually write plenty of programmers now without running into any, whereas before, you'd run into them all the time. - Jonathan M Davis

Yeah that's definitely very true. :) Sorry that the negative feedback seems to drown out anything that looks positive... but I've definitely noticed the improvement (and that's what makes me come back and try writing a program in D every once in a while). Props to you guys for the work!
Oct 24 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 25, 2012 at 04:46:04AM +0200, Era Scarecrow wrote:
 On Thursday, 25 October 2012 at 02:19:39 UTC, H. S. Teoh wrote:
 
Huh? Why would you drop classes in favor of structs? They are used
for two different purposes. Classes are for when you need
polymorphism: inheritance, overloading, interfaces, all the trappings
of OO programming. Structs are for when you need value types that
doesn't need OO-style manipulations. Not the same thing.

Indeed. Instead of interfaces you'd use templates, OO doesn't change really all that much. There's also large amounts of memory consumption that just isn't needed for data that hasn't and/or isn't going to change. More often I'm thinking structs w/templates are more powerful than classes.

Used correctly, *classes* with templates can be pretty powerful too. Recently I wrote an expression parser that can either parse the expression into a tree, or compute its value on-the-fly. I didn't like the idea of duplicating the parser code for both usages, so I decided to turn the parser into a template that would do one or the other. The template would call a static class method at key points during the parse, which alleviates the parser from knowing (or caring) what was done with the parsed expression -- the method could build a tree, or evaluate the expression, etc.. While I was coding that, I realized that lots of code is still being duplicated -- for example, to implement building a tree with +, -, *, and / operators _and_ to evaluate the same operators on-the-fly, required that operator-specific code be written in both classes. That was when I realized that I can leverage inheritance by factoring the operator-specific code into the base class, and overriding the static method in the derived class so that when the parser was instantiated with the base class, it built an expression tree, whereas when instantiated with the derived class, it would evaluate the expression. And moreover, the return type of the parser would be the derived class, so the caller doesn't even need to downcast to read the computed value. And all the while, the derived class can also be used as leaf nodes in the full expression tree, when building the latter. So even though things like templated virtual methods don't work, you *can* still make pretty potent combinations of templates + classes. T -- Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Funny, I was actually building a (GLR) parser, too.

Keeping track of duplicate item sets was what tripped me up.
Oct 24 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Oct 25, 2012 at 5:34 AM, Mehrdad <wfunction hotmail.com> wrote:
 Funny, I was actually building a (GLR) parser, too.

 Keeping track of duplicate item sets was what tripped me up.

H. S. Teoh, Mehrdad: are your codebases in a public website?
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 25 October 2012 at 05:11:38 UTC, Philippe Sigaud 
wrote:
 On Thu, Oct 25, 2012 at 5:34 AM, Mehrdad 
 <wfunction hotmail.com> wrote:
 Funny, I was actually building a (GLR) parser, too.

 Keeping track of duplicate item sets was what tripped me up.

H. S. Teoh, Mehrdad: are your codebases in a public website?

Nope. I'll consider releasing it when I make it decent, but right now, there's really nothing to put anywhere. (I've probably re-started like 6 times now, like twice with each language. Each one had its own downfalls; I tried D because I thought it would have great opportunities with CTFE and mixins. But so far the code has always been ugly and I've run into the problem of not really wanting to debug my own code.)
Oct 24 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Actually, I think I might as well send you a link to something I 
had in C#...

https://gist.github.com/203f8d65b60fe2d75339



Grab it before it's gone ;) I might delete it at some point.



It was meant to be my stab at what I _thought_ a "recursive 
ascent-descent parser" should do.

I really have no idea if it's correct or not, so be careful.

I also don't know if the code is buggy or not, so... yeah.
Oct 24 2012
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Thursday, 25 October 2012 at 02:12:58 UTC, Jonathan M Davis 
wrote:
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the 
 contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arrays do (or are supposed to anyway) and compare each member according to == and only fallback to an outright bitwise compare when it knows that the results would be identical (i.e. because all of the members are integral types, character types, bool, or other structs which hold only integral types, character types, or bool - be it directly or in other structs that they hold). Bitwise comparison is the is operator's job, not ==. - Jonathan M Davis

+1 I can only agree with this. People who monitor the NG know about the problem but it is probably very confusing to D newbies.
Oct 25 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 24, 2012 22:12:48 Jonathan M Davis wrote:
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way.

Actually, slight correction. Pointers are fine too. I'd expect to have to overload opEquals to get deep comparisons for those (and I expect that the same happens with arrays), but basically anything which isn't an integral value of some kind (which pointers essentially are) won't compare properly if the default opEquals for structs is doing the same as the is operator like it is right now. - Jonathan M Davis
Oct 25 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Oct 25, 2012 at 7:51 AM, Mehrdad <wfunction hotmail.com> wrote:
 Actually, I think I might as well send you a link to something I had in
 C#...

 https://gist.github.com/203f8d65b60fe2d75339



 Grab it before it's gone ;) I might delete it at some point.

Thanks :)
Oct 25 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 25, 2012 at 06:34:32PM -0700, Ellery Newcomer wrote:
 On 10/24/2012 01:16 PM, Mehrdad wrote:
On Wednesday, 24 October 2012 at 20:03:44 UTC, H. S. Teoh wrote:
What's wrong with RedBlackTree? You can just do something like:

    RedBlackTree!(RedBlackTree!MySet) setOfSets;

The last time I checked two RedBlackTrees for equality, they seemed to have reference semantics...

Dang. import std.container; import std.stdio; void main() { auto a = make!(RedBlackTree!int)(1,2,3,4); auto b = make!(RedBlackTree!int)(1,2,3,4); writeln(a == b); } prints false Explanation: RedBlackTree doesn't override opEquals. Either file an enhancement request or use equal(a[], b[]), depending on whether opEquals *should* have reference semantics.

Hmph. This is what I don't like about the built-in ==. Its semantics are inconsistent once you leave the realm of ints and floats and other numerical types. I think this one is worthy of a bug report.
 Actually, it shouldn't, since that would differ from array/string
 opEquals semantics.

Yeah, Jonathan is right, "==" should *always* do a deep compare, and leave "is" to do a shallow compare. Anything else is inconsistent, and leads to all kinds of pathological bugs. T -- Любишь кататься - люби и саночки возить.
Oct 25 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, October 26, 2012 19:46:16 deadalnix wrote:
 Le 25/10/2012 04:12, Jonathan M Davis a =C3=A9crit :
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if =


 struct only contains integral types, character types, or bool. Noth=


 else will compare properly that way. It really needs to work like a=


 do (or are supposed to anyway) and compare each member according to=


 and only fallback to an outright bitwise compare when it knows that=


 results would be identical (i.e. because all of the members are int=


 types, character types, bool, or other structs which hold only inte=


 types, character types, or bool - be it directly or in other struct=


 they hold). Bitwise comparison is the is operator's job, not =3D=3D=


=20
 - Jonathan M Davis

That will broke code. =20 But That is the way to go IMO. D needs to evolve to make things more consistent in general. =20 Still not doable without a proper versionning scheme.

TDPL clearly states that each of the struct's members are supposed to b= e=20 checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright= a bug=20 for structs to be checked for equality with a bitwise comparison when t= he=20 bitwise comparison does not do exactly what =3D=3D would have done had = each and=20 every member variable been compared with =3D=3D. And as with all bugs, = fixing it=20 could break code which depends on the buggy behavior. But given the nat= ure of=20 this bug, I seriously question that much of anyone thought that the =3D= =3D on=20 structs was supposed to do anything other than what TDPL states that it= should=20 and that pretty much no one was expecting it to do a bitwise comparison= . So,=20 if anything, this will _fix_ far more code than it breaks. - Jonathan M Davis
Oct 27 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Oct 27, 2012 at 07:52:37PM -0700, Jonathan M Davis wrote:
[...]
 TDPL clearly states that each of the struct's members are supposed to
 be checked for equality (see section 7.1.5.2, p. 258 - 259). It's
 outright a bug for structs to be checked for equality with a bitwise
 comparison when the bitwise comparison does not do exactly what ==
 would have done had each and every member variable been compared with
 ==. And as with all bugs, fixing it could break code which depends on
 the buggy behavior. But given the nature of this bug, I seriously
 question that much of anyone thought that the == on structs was
 supposed to do anything other than what TDPL states that it should and
 that pretty much no one was expecting it to do a bitwise comparison.
 So, if anything, this will _fix_ far more code than it breaks.

+1. I have to say I was surprised to find out about this after I started using D; after first reading TDPL, I had the impression that it was supposed to do the "right thing" (and the right thing being == on each field, which I assumed the compiler would optimize into a bitwise compare where possible). Let's fix this. T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
Oct 27 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
 He who does not appreciate the beauty of language is not worthy to bemoan
 its flaws.

That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;) - Jonathan M Davis
Oct 27 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 07:42, Era Scarecrow wrote:

   Both seem to have their own issues, although I'd say javascript is
 worse than PHP. (at least PHP runs on the server).

You can run JavaScript on the server too. -- /Jacob Carlborg
Oct 29 2012
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jonathan M Davis wrote:
 On Friday, October 26, 2012 19:46:16 deadalnix wrote:
 Le 25/10/2012 04:12, Jonathan M Davis a =C3=A9crit :
 On Wednesday, October 24, 2012 13:31:14 Walter Bright wrote:
 The default compare for structs is a bit compare of the contents.

Which definitely seems inherently broken. Doing that only works if the struct only contains integral types, character types, or bool. Nothing else will compare properly that way. It really needs to work like arr=



 do (or are supposed to anyway) and compare each member according to =



 and only fallback to an outright bitwise compare when it knows that t=



 results would be identical (i.e. because all of the members are integ=



 types, character types, bool, or other structs which hold only integr=



 types, character types, or bool - be it directly or in other structs =



 they hold). Bitwise comparison is the is operator's job, not =3D=3D.
=20
 - Jonathan M Davis

That will broke code. =20 But That is the way to go IMO. D needs to evolve to make things more consistent in general. =20 Still not doable without a proper versionning scheme.

TDPL clearly states that each of the struct's members are supposed to be=

 checked for equality (see section 7.1.5.2, p. 258 - 259). It's outright a=

 for structs to be checked for equality with a bitwise comparison when the=

 bitwise comparison does not do exactly what =3D=3D would have done had ea=

 every member variable been compared with =3D=3D. And as with all bugs, fi=

 could break code which depends on the buggy behavior. But given the natur=

 this bug, I seriously question that much of anyone thought that the =3D=

 structs was supposed to do anything other than what TDPL states that it s=

 and that pretty much no one was expecting it to do a bitwise comparison. =

 if anything, this will _fix_ far more code than it breaks.

I was looking for that section. 3789 is clearly a bug and should be fixed as soon as possible. Votes indicate how important a bug should be. But duplicates are also a good indicator. This bug has six duplicates. Jens
Oct 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Oct 27, 2012 at 10:42:21PM -0700, Jonathan M Davis wrote:
 On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
 He who does not appreciate the beauty of language is not worthy to
 bemoan its flaws.

That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)

Wait, are you saying that D is one big flaw? ;-) T -- Ph.D. = Permanent head Damage
Oct 28 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 27 Oct 2012 22:42:21 -0700
Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
 He who does not appreciate the beauty of language is not worthy to
 bemoan its flaws.

That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)

Did someone say "PHP"? ;)
Oct 28 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 29, 2012 at 01:28:51AM -0400, Nick Sabalausky wrote:
 On Sat, 27 Oct 2012 22:42:21 -0700
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 
 On Saturday, October 27, 2012 22:30:25 H. S. Teoh wrote:
 He who does not appreciate the beauty of language is not worthy to
 bemoan its flaws.

That presupposes that the language has any beauty to begin with. It could just be one big flaw. ;)

Did someone say "PHP"? ;)

I thought I heard "Javascript"... :-P T -- In theory, there is no difference between theory and practice.
Oct 28 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 29 October 2012 at 05:43:43 UTC, H. S. Teoh wrote:
 On Mon, Oct 29, 2012 at 01:28:51AM -0400, Nick Sabalausky wrote:
 Did someone say "PHP"? ;)


Both seem to have their own issues, although I'd say javascript is worse than PHP. (at least PHP runs on the server).
Oct 28 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Sunday, 28 October 2012 at 05:28:20 UTC, H. S. Teoh wrote:

 I have to say I was surprised to find out about this after I 
 started
 using D; after first reading TDPL, I had the impression that it 
 was
 supposed to do the "right thing" (and the right thing being == 
 on each
 field, which I assumed the compiler would optimize into a 
 bitwise
 compare where possible).

 Let's fix this.

There is a problem with floating point memebers, since nan values will always compare false. There's other things in D that bother me, such as how struc pointers are managed, where they sometimes behave exactly like class references, but not always. The inconsistent behaviour is a trap for the programmer to fall into, and it leads to subtle hard to find errors. For example: struct S { int a; ~this() {} } class C { int a; ~this() {} } // identical behaviour auto Sp = new S; auto Cr = new C; // identical behaviour writeln(Sp.a); writeln(Cr.a); // identical behaviour auto Sp2 = Sp; auto Cr2 = Cr; writeln(Sp2.a); writeln(Cr2.a); // ? assert(Sp2 == Sp); assert(Cr2 == Cr); // different behaviour! clear(Sp); clear(Cr); Last two line compile OK, but clear(Sp) does not invoke the destructor while clear(Cr) does. clear(*Sp) works, but why allow clear(Sp) if it's a pointless operation? Is this a bug in the compiler or with the language design? Subtle differences like this are very nasty. The code should behave identically for both the struct pointer and the class reference, and if this is not poosible for some obscure reason, then the compiler should fail at the clear(Sp) line. If I invoke with clear(*Sp) it works, but the inconsistency makes template code that takes in both a struct or a class impossible to do (or at best needlessly difficult to do). --rt
Oct 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote:
[...]
 There is a problem with floating point memebers, since nan values will
 always compare false.

This is IEEE specification. There is no problem. T -- Frank disagreement binds closer than feigned agreement.
Oct 29 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 29 October 2012 at 18:39:41 UTC, H. S. Teoh wrote:
 On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote:
 [...]
 There is a problem with floating point memebers, since nan 
 values will
 always compare false.

This is IEEE specification. There is no problem. T

If struc comparisions compare value by value, and both have Nan values in one member variable, then the two otherwise completely identical structs will always compare false even though they are identical. I think it would be best to have the ability to compare structs in two ways, one as struct equivalence, which would be the default method, the other as vale by value equivalence, which would have to be programmer defined through overload of == operator. --rt
Oct 29 2012
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 29 October 2012 at 19:55:41 UTC, Rob T wrote:
 On Monday, 29 October 2012 at 18:39:41 UTC, H. S. Teoh wrote:
 On Mon, Oct 29, 2012 at 06:34:14PM +0100, Rob T wrote:
 [...]
 There is a problem with floating point memebers, since nan 
 values will
 always compare false.

This is IEEE specification. There is no problem. T

If struc comparisions compare value by value, and both have Nan values in one member variable, then the two otherwise completely identical structs will always compare false even though they are identical. I think it would be best to have the ability to compare structs in two ways, one as struct equivalence, which would be the default method, the other as vale by value equivalence, which would have to be programmer defined through overload of == operator. --rt

I understand the problem, but it doesn't seem related to structs at all. Any two attempts to compare two default-valued floats will fail, irrespective of whether or not they're inside structs.
Oct 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-30 17:09, Tobias Pankrath wrote:

 I agree, that the online docs are insufficient for learning the
 language.
 But that's the case for phobos, too. Both are just a listings of
 what is there and don't give you any overview of what design
 decisions were made and what implications they have.

 Just take a look std.container.

 I hope that Ali Çehreli efforts will be midterm solution at
 least for the language docs. Maybe he should credits by linking
 from the homepage to his book.

A language needs several types of documentation. Reference documentation (basically what we have now), higher level documentation, tutorials and examples. -- /Jacob Carlborg
Oct 30 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Tuesday, 30 October 2012 at 02:27:30 UTC, Mehrdad wrote:
 I understand the problem, but it doesn't seem related to 
 structs at all.

 Any two attempts to compare two default-valued floats will 
 fail, irrespective of whether or not they're inside structs.

True at the level of float by float comparisons, but not necessarilly true when struct by struct bit pattern compares are done. My original understandiong of the struct type in D, is that it is defined as a POD which means == (without override) is done as a simple bit pattern compare, rather than doing a value by value compare of member data types. If this is the case, then two structs with default valued equivalent float types should compare equal, even though a value by value compare would compare not equal.
 TDPL clearly states that each of the struct's members are 
 supposed to
 be checked for equality (see section 7.1.5.2, p. 258 - 259).

So I guess that the POD definition of struct was changed at some point? If so, then how are value by value compares performed when unions are involved? What about when there are member pointers, and other structures that cannot be compared in a meaningful way by default? I guess the question is if the bit pattern comparision of structs has sufficient justification to be worth having as the default behaviour, or if there is more value attempting a value by value comparision, even though in many situations it may be pointless to attempt either strategy. In my experience, I cannot recall doing very many direct struct comparisons either as a complete value by value compare or as a full bit pattern compare, I just never found it to be all that useful, no matter, I can try and imagine both strategies being useful in some situations. With operator overloading you can have both strategies, but only if bit pattern compare is the default stategy, plus with overloading, compare can do exactly what you want to make sense out of unions and pointers, etc. So we should be good as is. I would expect that most times no one compares structs fully by value or by bit pattern anyway, to do so very often is difficult for me to imagine, but I could be wrong. --rt
Oct 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 30, 2012 08:14:59 Rob T wrote:
 TDPL clearly states that each of the struct's members are
 supposed to
 be checked for equality (see section 7.1.5.2, p. 258 - 259).

So I guess that the POD definition of struct was changed at some point?

Structs never were just PODs in D. They have _way_ more capabilities to them than that. If you want bitwise comparison, then use the is operator. That's what it's for. - Jonathan M Davis
Oct 30 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Tuesday, 30 October 2012 at 07:22:30 UTC, Jonathan M Davis 
wrote:
 On Tuesday, October 30, 2012 08:14:59 Rob T wrote:
 TDPL clearly states that each of the struct's members are
 supposed to
 be checked for equality (see section 7.1.5.2, p. 258 - 259).

So I guess that the POD definition of struct was changed at some point?

Structs never were just PODs in D. They have _way_ more capabilities to them than that.

I do understand what you are saying, however the docs in here describe structs as POD's, with the capabilities you mention. http://dlang.org/glossary.html#pod
 If you want bitwise comparison, then use the is operator. 
 That's what it's
 for.

Where can I find an up-to-date language reference? What I'm reading does not seem to be up to date or complete. For example, I never saw mention of the "is" operator until now. --rt
Oct 30 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, October 30, 2012 08:37:47 Rob T wrote:
 Where can I find an up-to-date language reference? What I'm
 reading does not seem to be up to date or complete. For example,
 I never saw mention of the "is" operator until now.

It's in the online docs: http://dlang.org/expression.html It's in the "Identity Expressions" section. The best reference is TDPL though. - Jonathan M Davis
Oct 30 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 Where can I find an up-to-date language reference? What I'm 
 reading does not seem to be up to date or complete. For 
 example, I never saw mention of the "is" operator until now.

 --rt

It's hard to find because it can not be overloaded. Look here: http://dlang.org/expression.html#IdentityExpression In TDPL it's explained as well.
Oct 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 08:57:01AM +0100, Tobias Pankrath wrote:
Where can I find an up-to-date language reference? What I'm
reading does not seem to be up to date or complete. For example, I
never saw mention of the "is" operator until now.

--rt

It's hard to find because it can not be overloaded. Look here: http://dlang.org/expression.html#IdentityExpression In TDPL it's explained as well.

Sigh, one of these days I'm gonna have to rewrite many of these pages. I find them very hard to navigate and very unfriendly to newbies, because very basic information (like what 'is' is) is buried deep in long verbose infodumps of diverse language features, with no indication at all which are fundamental concepts and which are just details. It's virtually impossible to find what you're looking for unless you already know what it is. TDPL lays things out in a much saner fashion, but how many newbies actually own the book? We need the online docs to be just as newbie-friendly. T -- MSDOS = MicroSoft's Denial Of Service
Oct 30 2012
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 Sigh, one of these days I'm gonna have to rewrite many of these 
 pages.
 I find them very hard to navigate and very unfriendly to 
 newbies,
 because very basic information (like what 'is' is) is buried 
 deep in
 long verbose infodumps of diverse language features, with no 
 indication
 at all which are fundamental concepts and which are just 
 details. It's
 virtually impossible to find what you're looking for unless you 
 already
 know what it is.

 TDPL lays things out in a much saner fashion, but how many 
 newbies
 actually own the book? We need the online docs to be just as
 newbie-friendly.

I agree, that the online docs are insufficient for learning the language. But that's the case for phobos, too. Both are just a listings of what is there and don't give you any overview of what design decisions were made and what implications they have. Just take a look std.container. I hope that Ali Çehreli efforts will be midterm solution at least for the language docs. Maybe he should credits by linking from the homepage to his book.
Oct 30 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 08:50:50PM +0100, Jacob Carlborg wrote:
 On 2012-10-30 17:09, Tobias Pankrath wrote:
 
I agree, that the online docs are insufficient for learning the
language.  But that's the case for phobos, too. Both are just a
listings of what is there and don't give you any overview of what
design decisions were made and what implications they have.

Just take a look std.container.

I hope that Ali ehreli efforts will be midterm solution at
least for the language docs. Maybe he should credits by linking
from the homepage to his book.

A language needs several types of documentation. Reference documentation (basically what we have now), higher level documentation, tutorials and examples.

I contend that much of the current documentation isn't even up to reference standard. Incompleteness, for one thing. Things like Throwable and Exception aren't even documented right now (though this has been fixed in git HEAD). I'm sure there are many other fundamental holes. And a randomly-sorted list of unrelated module items does not constitute a reference, either. It has to be at least sorted alphabetically, or preferably, by logical categories. And things like class members need to be properly indented (I think this was fixed recently) instead of being flattened out, making it impossible to discern whether it belongs to the previous declaration or the global module scope. Moreover, nested classes/structs, etc., need to be put AFTER simpler members. It's basically unreadable when, for example, two int members are separated by the docs of a 2-page nested struct. And don't even get me started on navigability. Dumping a morass of #-links at the top of the page does not a navigable page make. Some modules NEED to have docs split into separate pages. A 10-page infodump of randomly sorted items is simply impossible to use effectively. Clickable identifiers would be nice, so that you don't have to separately navigate and lookup a particular symbol when you're not sure what it means, while trying to keep track of where you left off (and I thought we were in the age of automation...). T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Oct 30 2012