TSa: > Ruud H.G. van Tol: >> 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.
Yes for lists, but I see ^5 as an ordered set (with only unique elements). As domains: [0,5> + <0,8] = [0,8] The '+' was probably not the right symbol, a set-union-symbol would be better. Or a circled-plus (direct sum), the empty range being the zero vector. ^5 U 1..8 = ^9 As in arrays of a specific type: there can only be one value (of that type) at index $i (or of course no value at all, when $i is outside the index-range, or where a sparse array has a hole). >> 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; You just made me giggle again, sorry. >>> 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? I certainly was. I felt that you pointed out several inconsistencies that (I now think) resulted from my lack of understanding the history of the '^', and that made me giggle (of insecurity), which as I wrote my daughter duly noticed. > 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 s/1000/1001/ > > @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? No, I'm swimming again. Sparse arrays with only prime indices will haunt me in my sleep tonight. -- Grtz, Ruud
