[m-dev.] For review: updates to library/rbtree.m

[Warwick Harvey]

I wrote:
> Probably the easiest way to get a handle on this (and verify that it
> indeed has nothing to do with the rbtree module or any of my debugging
> hacks) is to change the implementation of merge in some pristine sources
> so that it does actually flag duplicated keys.  The current
> implementation is:
> 
> map__merge(M0, M1, M) :-
>         map__to_assoc_list(M0, ML0),
>         map__to_assoc_list(M1, ML1),
>         list__merge(ML0, ML1, ML),
>         map__from_sorted_assoc_list(ML, M).
> 
> I always thought this was a bit of an odd way to implement it, even if
> it was nice and clean.  I'd suggest something like:
> 
> map__merge(M0, M1, M) :-
>         map__to_assoc_list(M1, ML1),
>         map__det_insert_from_assoc_list(M0, ML1, M).
> 
> (or the reverse, adding the contents of M0 to M1, if one thinks perhaps
> M1 tends to be bigger than M0).
> 
> Then bootcheck the compiler, and see if it barfs.

FYI, I did this (I hate making claims that bugs aren't in my code until
I can really prove they're elsewhere).  The compiler barfed building the
majority of the stage 2 library files with the following error:

Uncaught exception:
Software Error: map__det_insert: key already present
        Key Type: term:var(prog_data:tvar_type)
        Key Functor: var/1
        Value Type: hlds_pred:type_info_locn
Stack dump not available in this grade.

Cheers,
Warwick
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------