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!

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.

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?

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.)

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.

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

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.

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

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 :)

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.