>I'm not understaning your position.
We don't have very long names for function names. Our functions
scan left to right, although our postfix modifiers alter that
picture. And something like "union" or "intersection", long and
alphabetic, certainly looks like a function name.
My position is that we don't currently have a way to create
user-defined function that works as an infix. Are we really wanting
to create something as a built-in that a user can't create for his
own types? Perhaps.
>I could have used such an operation
>rather than rolling my own. And a module would be too heavy handed for
>such a simple concept.
It's not a simple concept: arrays are not sets, and seldom are a
good representation for the same due to efficiency and to countability.
And it does merit a module. And we already have some.
For that matter, we don't have non-prefix operators that operate on pairs
of operands that are lists, arrays, or hashes. Well, unless you want to
call comma an infix in @a = (@b, @c). But commas and parens are special.
What I'd like to see is a real general-purpose proposal out of which
this set crud might be merely an instance of. Here are some example steps
down that route. These are not concrete suggestions:
Given that:
We no longer believe that scalar operators should operate on scalars
alone.
We no longer believe that scalar operators applied to aggregates
should autocoerce those aggregates.
We no longer believe that implicit distribuive application
of scalar operators is a bad idea.
We no longer believe that if it looks like a function, that it
should act like a function.
We no longer believe that the set of operators in Perl
should be restricted to those same names, precedences,
associativities, and arities as correspond to the built-in
operators.
(etc)
We therefore propose to create:
A general-purpose mechanism to denote a function as occupying
a particular slot, whether prefix or postfix or infix, along
with their prototypes (context coercion templates),
precedences, arities, and associativities. These functions'
profiles need not correspond to anything that exists in
Perl today.
This would be useful, for example, in creating pre-defined set-related
op codes.
I think you still have some big hurdles here, however. Lists are crappy set reps.
--tom