Re: [q-lang-users] Association lists

[Jiří S. <jir...@bl...>]

Albert Graef wrote:
> Ok, thanks a lot. I did some more reformatting so that the layout is
> more in line with the rest of the library, and fixed a couple of minor
> bugs and typos. I also removed the do/map stuff in dict.q (while this
> might be useful, I'd prefer the new version to be a drop-in replacement
> for the old one for now). It is in cvs now.

OK.

> There's still a minor issue with the inserta/deletea operations,
> however. The problem is that you used syntactic equality (foo X X = ...)
> rather than (=) to decide equality of two key values. That will be ok in
> most cases (hdict should be fine as the real key there is always an
> integer), but for dict/bag/set you don't know what the actual key type
> is, it may be *any* ordered type, and some key types might well use a
> version of (=) which goes beyond simple syntactic equality, see
> "Non-Linear Equations" in the manual
> [http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC42] for an explanation.
> I'll try to fix this (shouldn't be too difficult) and give it a first
> test drive with a couple of my programs. If that works ok I'll upload a
> new release candidate later today.

I see, you are right.

However I fall in problems when using my libraries together. Whether it 
works depends on the order in which I import them

Eg. if I do

import set, dict;

then I receive this conversation:

==> insert emptydict (1,1)
fst (set::inserta (dict []) (1,1))

and even with qualified call

==> dict::insert emptydict (1,1)
fst (set::inserta (dict []) (1,1))

When I change the import order, ten it is OK:

import dict, set;

==> insert emptydict (1,1)
dict [(1,1)]

==> insert emptyset 1
set [1]

Other two libraries behave similarly. I cannot find any bad declarations 
(eg. public instead of private). This may be related to the fact, that 
my versions of inserta have different arity for dict and set while your 
corresponding functions have the same arity.


BTW I was a bit surprised, that this works:

==> set::inserta emptyset 1
(set [1],true)

I wuould expect, that private functions are not accesible at all, but 
this may be an intention.

Regards,

Jiri