On Tuesday, 9. November 2010 01:45:52 Mason Kramer wrote:
> I have to disagree here. Arrays and Hashes may be about storage (I don't
> think they are, though, since you can change the (storage) implemenation of
> an Array or Hash via its metaclass and it can still remain an Array or
> Hash).
What I mean with storage is that you put some data into a numbered slot
in an array and a keyed slot into a hash. With the same index or key you
can retrieve your data at any time. This is the case irrespective of the
underlying implementation. A set is not about storage in this sense, because
there is no way of retrieving an element. The only operation is a membership
test which is of boolean nature like number comparison.
> The most important part of the @ sigil, and the reason I preferred it over
> $, is that @ "flattens" (moritz++'s word), when used in a list context such
> as for @blah,
> map {...}, @blah.
I wonder if it is not possible to bind flattening to Iterable. This of course
has the drawback that it is not syntactically distinguished. But doesn't
my $x = (1,2,3);
my $y = map {$^x * $^x}, $x;
result in $y containing the list (1,4,9)? And if $x happens to be a scalar
isn't it just squared? In the end we just need &map:( &closure, Set $data -->
Set) as an overload. Or perhaps &map:( &closure, Iterable ::T $data --> T).
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
