HaloO,
Ruud H.G. van Tol wrote:
Not at all: they just overlap at 0.
OK, to me this spoils regularity. Like 'ab ' ~ ' xy'
becoming 'ab xy' is at least surprising, if not outright wrong.
That is
(~$x).chars + (~$y).chars == +((~$x) ~ (~$y))
should always hold. Same thing for list concatenation which
in Perl6 is provided by comma
(-3,-2,-1,0),(0,1,2,3) »==« (-3,-2,-1,0,0,1,2,3) »==« -3..0,0..3
where the length of each is 4 + 4 == 8.
I hope those all resulted from the spoiling step, because I got lost.
Well, I tried to argue for maintaining ^ as the kind/type capture
sigil and make it available for structural analyses of arrays.
my ^x ^y ^z [EMAIL PROTECTED] = ( ( ( 1, 2); ( 3, 4); ( 5, 6) );
( ( 7, 8); ( 9,10); (11,12) );
( (13,14); (15,16); (17,18) );
( (19,20); (21,22); (23,24) ) );
[EMAIL PROTECTED] == 24; ^a == Array[^24] of Int;
+^z == 24; ^z == (0..23).kind;
+^y == 12; ^y == (0..11).kind;
+^x == 4; ^x == (0,1,2,3).kind;
This depends if capturing is from the outer-level inwards or the
other way round. In my example ^x captures the outer dimension.
But that could also appear in ^z and ^y and ^x would then drill
further into the structure of the type.
And ^0 is *the* empty list.
Unintentional, but that's how many great things are found.
You are not trying to make fun of me? What I tried to say is,
that ^0 is the empty list type, not an empty list value. That
is (,). In other words
$foo = ^0; # syntax error or on the fly type instanciation?
Note that as Larry set up this thread, this would now be
written
$foo = ::0;
again. At it does not look like an empty list anymore.
In a more detailed view the type of ^3 might actually
be :(0=>0, 1=>1, 2=>2) or with the arrow :(0-->0, 1-->1, 2-->2).
And ^3.0 might be :(0=>0, 1=>0, 2=>0).
This nicely lifts Juerds concerns about mixing the last index as
ordinal number with the cardinal number of elements in the array
from the value level up to the type level. Not making off-by-one
errors is easier for the compiler than the programmer ;)
Apart from having a nice syntax for ranges I would like to get
array variables as *the* integer variables when you don't happen
to care for the data in the array. That is things like
my @a = 10;
my @b = -3;
say @a + @b; # prints 7
should first of all be allowed and imply proper integer semantics
at a neglectable performance cost if any. And I wouldn't mind if this
arithmetic spilled over to concatenating the lists of data in the array
lazily at the top level:
@a = (0,1,2);
@b = (3,4,5,6);
@c = @a + @b; # higher precedence than (@a,@b)
say [EMAIL PROTECTED]; # prints 7
say @c[]; # prints 0 1 2 3 4 5 6
This would also allow the distinction of
@a = 1..3; # [EMAIL PROTECTED] == 3
@b = 1000..1003; # [EMAIL PROTECTED] == 3
@added = @a + @b; # @added = (1,2,3,1001,1002,1003); [EMAIL PROTECTED] == 6
and
@range = @[EMAIL PROTECTED]; # @range = 1..1003; [EMAIL PROTECTED] = 1003
@range[207] == undef;
BTW, should then
@range[20000] = 99;
add a single element separated by a 18997 elements long gap and
consequently [EMAIL PROTECTED] == 1004? This would re-optimize the index-set
on assignment:
@packed = @range; # [EMAIL PROTECTED] == [EMAIL PROTECTED] == 1004
# but @packed.last == 1003 and @range.last = 20000
say @packed[1003]; # prints 99
What were the advantage of [EMAIL PROTECTED] == 20001? Other than
allowing the dubious @range.last == [EMAIL PROTECTED] - 1? The gap
could be made fillable by something to the effect of
@range.replenish(42); # fills undef cells eagerly, thus [EMAIL PROTECTED] ==
20001
@range.gaps = 23; # lazy fill and [EMAIL PROTECTED] == 1004 but
say @range[9999]; # prints 23
Comments?
--
$TSa.greeting := "HaloO"; # mind the echo!
