Gael Pegliasco wrote:
>
>> So what if the man wants
>>
>> @foo = @bar union @baz;
>> @foo = @bar intersetcion @baz;
>>
>> This is a lot more of a direct map than the twiddling with hashes.
>>
>> How are you drawing the line. Where does giving the user more power
>> than a turing machine stop.
>>
>> <chaim>
>
>
>Yes Baby !
>
>This sound good for me !
>
>I'm completly ok with this new syntax, it is much better than a function
>!
The underlying problem is that arrays don't make SENSE as an
implementation for sets. What is the value of:
(1, 2, 3, 1, 2, 3) union (2, 3, 4, 5) ?
is it (1, 2, 3, 4, 5)? is it (1, 2, 3, 1, 2, 3, 4, 5)?
(1, 2, 3, 1, 2, 3) is NOT a valid set. The problem GOES AWAY if you
make a small mental shift and deal with HASHES instead of ARRAYS.
(1, 2, 3, 1, 2, 3) CANNOT be the keys of a hash -- the language
ALREADY enforces this!
Why reinvent the wheel when there's already half a wheel there?
IF new keywords "union" and "intersection" (and perhaps others)
are to be added to the language, they should be functions that
operate on the KEYS of HASHES, not on arrays!
And, imho, these are special-purpose functions that are going to be
extremely useful to a fairly small set of users (math folks), and
are going to be somewhat useful to another small set of people,
and fairly useless to the majority of Perl programmers. That screams
"module" to me, not "new core features".
----------------------------------------------------------------------
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer 'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation '.r', 'h ', 'uj', 'p ', 'ts';
