your thinking of nested structures I'm thinking of objects. If you have instances representing something like "Employees" you don't wanna identify twins.

> so do the same test as == against the reference itself (the address).

Actually it's eq, think about the way scalars are compared.

> The user wants to find the intersection of two lists, so he would be told to pass @set1 and @set2, and optionally a &func, which defaults to built-in stringification.

I was already meditating about this, I also like the Python approach (where sets are a built-in datatype) to make the hash function operate on the basis of an "equality" method of "hashable" objects. (but I don't know how this is efficiently implemented) IIRC it's possible in Perl to overload the way objects are stringified.

>If I want two ad-hoc uses of [qw/1 2 3/] to be considered the same, stringifying the reference won't do it.

IMHO sets of "deeply compared" nested structure are better done with nested hashes. (kind of a tree search for each level of nesting)

> And we suppose that this (the key function) is expensive, so only call it once per value in each input list.

agreed.

BTW: interesting read

update: fixed unescaped brackets