Re: type sigils redux, and new unary ^ operator
TSa:
Perhaps we
can live with the numerically lower end always beeing part
of the range, the larger one never,
I don't think so.
0 .. 5 == ( 0, 1, 2, 3, 4)
{ action } for 0 .. 5
is supposed to run for 0,1,2,3,4,5.
But '0 .. ^5' should not mean '( 0, 1, 2, 3, 4, 5)' just because
scalar(^5) is 5.
0 .. ^5 = 0 .. 0 .. 4 = 0 .. 4
I think that '0..^0' should be the empty range, just as '^0'.
0 ..-5 == (-1,-2,-3,-4,-5)
Maybe only a range from low to high should be auto-listified, and a
bare '0..-5' should remain an error.
(0 ..-5) == (0, -1,-2,-3,-4,-5)
-5 .. 5 == (-5,-4,-3,-2,-1, 0, 1, 2, 3, 4)
-5 .. ^5
--
Affijn, Ruud
Gewoon is een tijger.
Re: type sigils redux, and new unary ^ operator
HaloO, Michele Dondi wrote: IMHO the former is much more useful and common. Mathematically (say, in combinatorics or however dealing with integers) when I happen to have to do with a set of $n elements chances are to a large extent that it is either 0..$n or 1..$n; 0..$n may lead to confusion since it it actually has $n+1 elements. Not to mention border cases like 0..0 == (0, 0) or (0,)? How many elements should $x..$y have in general? In particular when fractional parts are allowed like in $x = 3.2 and $y = 4.6. Does that yield (3.2, 4.2) or (3.2, 4.2, 4.6) to reach the end exactly? Or would a non-integer number force the range to have infinitely many members? How do ranges relate to list concatenation? (0..4,4..6) looks odd, but then would better be written (0..6) if no double entry 4 is intended. Perhaps we can live with the numerically lower end always beeing part of the range, the larger one never, irrespective of the side of the .. they are written on. Swapping them just means reversing the list: 0 .. 5 == ( 0, 1, 2, 3, 4) -5 .. 0 == (-5,-4,-3,-2,-1) 0 ..-5 == (-1,-2,-3,-4,-5) -5 .. 5 == (-5,-4,-3,-2,-1, 0, 1, 2, 3, 4) which is how array indices work as well. This also gives proper modulo semantics which is 5 in all cases above, and applied two times in the last line. --
Re: type sigils redux, and new unary ^ operator
HaloO, 0 .. 5 == ( 0, 1, 2, 3, 4) Hmm, and 0..5.1 == (0,1,2,3,4,5) to rescue the end. --
Re: type sigils redux, and new unary ^ operator
Juerd:
Ruud H.G. van Tol:
Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
It's not about problems in execution,
That answers when not. :)
it's about expression.
Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
Maybe someone doing
for ([EMAIL PROTECTED])-$i { say @foo[$i] }
That should be ^(@foo.last + 1),
Yes, but such a 'someone' doesn't care, so why take him in account?
or not using ^ at all. I'd prefer the
latter.
As a domain-notion, I like ^.
--
Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
On Wed, 23 Nov 2005, Peter Scott wrote: It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n. IMHO the former is much more useful and common. Mathematically (say, in combinatorics or however dealing with integers) when I happen to have to do with a set of $n elements chances are to a large extent that it is either 0..$n or 1..$n; 0..$n may lead to confusion since it it actually has $n+1 elements. Michele -- My fiancee asked me to do invitations, and she's going to get it done the right way -- the TeX way. Good choice. One would never want to go through the same thing again for a divorce. Better than rings and vows. - David Kastrup in comp.text.tex, Re: Simple Wedding Invitations in LaTeX2e
Re: type sigils redux, and new unary ^ operator
Juerd: Larry Wall: [Peter Scott]: It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n. But then you'd usually want 1..$n instead... I think this illustrates very well that it's a bit silly to have a shortcut for just one of the three much-used ranges. But is it (just) that? ^5 0 .. 4 ^$n0 .. $n-1 [EMAIL PROTECTED] 0 .. @a.elems-1 (usage deserves a warning) [EMAIL PROTECTED]zip: @a.keys? @a.indices? ?? 0 .. @a.last-1 (no sc ncsry, prbly no need @all) ?? 1 .. $n (no sc ncsry, or use base-0) ?? 0 .. $n+1 (no sc ncsry) Indexes and numbers (counts) just aren't the same thing, and I think source code should communicate meaning using the right words. Indices can be sets of sparse ranges. A sparse range is a set of non-sparse ranges. [7..13; 0..5, 9..Inf]. The word for the last index is .last, that of the number of elements is .elems, or [EMAIL PROTECTED] If you need the last index, plus one, you shouldn't use the number of elements, and if you need the number of elements, minus one, you shouldn't use the last index. Am I the only one who cares about this distinction? No. -- Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
Ruud H.G. van Tol skribis 2005-11-24 10:36 (+0100):
it's about expression.
Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
No.
However, it does feel weird to have an *operator* that makes an array
behave in a certain way. Well, not weird, because we're used to context,
but operators usually don't carry their own dedicated context. I think a
method would be a bit saner.
I think that
for @foo.indexes { ... }
is a lot clearer, to everyone, than
for [EMAIL PROTECTED] { ... }
If .indexes turns out to be used a lot, then let's have .i -- i for
index is accepted abbreviation, isn't it? (Think for (i = 0; ...;
...))
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
Ruud H.G. van Tol skribis 2005-11-24 12:25 (+0100): [EMAIL PROTECTED]zip: @a.keys? @a.indices? Special syntax, or special context? Indices can be sets of sparse ranges. A sparse range is a set of non-sparse ranges. [7..13; 0..5, 9..Inf]. I have no objections to [EMAIL PROTECTED] returning a list of indexes, if that is the definition. I do object to [EMAIL PROTECTED] meaning [EMAIL PROTECTED], which happens to return a list of indexes for most arrays. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
Rob Kinyon skribis 2005-11-24 0:44 (-0500): What about @array.indices instead? Oops, I said indexes in a former message. Maybe a good candidate for an alias? Then, there's no possible fenceposting, your code is self-documenting, and we're not introducing another unary operator? ++ Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
Juerd: I have no objections to [EMAIL PROTECTED] returning a list of indexes, if that is the definition. It is what Mark suggested. Rob suggested to use .indices instead. Looking at 'elem(ent)s' and 'ind(exe)s' and 'ind(ice)s', I toss up 'inds' or 'ixs'. I do object to [EMAIL PROTECTED] meaning [EMAIL PROTECTED], which happens to return a list of indexes for most arrays. You see, you were never alone. ;) -- Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
Juerd: Rob Kinyon: What about @array.indices instead? Oops, I said indexes in a former message. AFAIK they share most of their meanings nowadays. (My old Chambers says that indexes are books.) Maybe a good candidate for an alias? No doubt about it. -- Affijn, Ruud Gewoon is een tijger.
Re: type sigils redux, and new unary ^ operator
HaloO, Ruud H.G. van Tol wrote: Yes, it could use a step: ^42.7 = (0, 7, 14, 21, 28, 35) ^42.-7 = (35, 28, 21, 14, 7, 0) OK, fine if the step sign indicates reversal after creation. That is, the modulus is 7 in both cases. ^-42.7 = (-35, -28, -21, -14, -7, 0) ^-42.-7 = (0, -7, -14, -21, -28, -35) I would make these ^-42.7 == (-42, -35, -28, -21, -14, -7) ^-42.-7 == ( -7, -14, -21, -28, -35, -42) and (^-42.7 + ^42.7) has length 11, maybe better expressed as ^-42.7.42, And the fact that you concatenate two six-element lists and get one with *11* elements doesn't strike you as odd? I find it very disturbing! E.g. when shifting by 42 rightwards I would expect ^-42.7.42 == (-42, -35, -28, -21, -14, -7, 0, 7, 14, 21, 28, 35) to become ^84.7 == (0, 7, 14, 21, 28, 35, 42, 49, 56, 63, 70, 77) and of course ^84.7 »- 42; or to more resemble your notation -42 +« ^84.7; beeing two other forms to write this kind. Ahh, and should there be a warning about a remainder for ^45.7 == (0, 7, 14, 21, 28, 35, 42) # rest 3 and how should a negative---err---endpoint be handled? I opt for ^-45.7 == (-49, -35, -28, -21, -14, -7) # rest 4 But the warning could be avoided with some dwimmery after we observe that 45 == 42 + 3 and -45 == -49 + 4 the respective rests mean to shift the list rightwards accordingly ^45.7 == (3, 10, 17, 24, 31, 38, 45)# shift right 3 ^-45.7 == (-46, -39, -30, -23, -18, -11, -4) # same ^-45.7 == (-45, -38, -31, -24, -17, -10, -3) # shift right 4 ^45.7 == (4, 11, 18, 25, 32, 39, 46)# same If you find the above odd, than use the homogenious cases ^45.7 == ( 3, 10, 17, 24, 31, 38, 45) # shift right 3 and ^-45.-7 == (-3, -10, -17, -24, -31, -38, -45) # reversed shift right -3 == -« ^45.7 which results in pairwise nullification as expected ^45.7 »+« ^-45.-7 == ^7.0 == (0,0,0,0,0,0,0) Let's switch to a shorter example list and use the , to build some subsets of int ^-21.7.0 , ^21.7.0 == (-21, -14, -7, 0, 7, 14) # length: 42/7 == 6 ^-21.7.1 , ^21.7.1 == (-20, -13, -6, 1, 8, 15) ^-21.7.2 , ^21.7.2 == (-19, -12, -5, 2, 9, 16) ^-21.7.3 , ^21.7.3 == (-18, -11, -4, 3, 10, 17) ^-21.7.4 , ^21.7.4 == (-17, -10, -3, 4, 11, 18) ^-21.7.5 , ^21.7.5 == (-16, -9, -2, 5, 12, 19) ^-21.7.6 , ^21.7.6 == (-15, -8, -1, 6, 13, 20) ^-21.7.7 , ^21.7.7 == (-14, -7, 0, 7, 14, 21) If the lists where extended on both sides to infinity then a shift of 7 changes anything, as can be seen from the last line. Hmm, the syntax is ambigous with respect to the . if we want to allow steps 1. Looks like a jobs for the colon: ^21:7:0 == (0, 7, 14) ^1:0.25 == (0, 0.25, 0.5, 0.75) ^1:0.2:0.2 == (0.2, 0.4, 0.6, 0.8, 1.0) which perhaps just mean ^1:step(0.2):shift(0.2) Please note that all of the above are *list literals* not prefix ^ operator invocations. If one wants to become variable in this type/kind then a @var is needed. A ^$x might be just a short form of capturing the kind of $x into ^x which not auto-listifies. Thus my ^x $x = 7; say ^x; # Int say +$x; # 7 but my ^a @a = (0,0,0); say [EMAIL PROTECTED]; # 3 say ^a; # Array is shape(3) of Int # Array[^3] of Int # Array[ shape = 3, kind = Int ] or however the structure of an array is printed. which makes '^5' the short way to write '^5.1.0'. And ^0 is *the* empty list. Hmm, and ^Inf.0 the infinite list full of zeros (0, 0, 0, ...), ^Inf.1 are of course the non-negative integers in a list (0, 1, 2, ...). Then if we hyperate it and pick the last entry (^Inf.1 »+ 1)[-1] we get the first transfinite ordinal Omega[0]. From there we keep counting transfinitely... And of course 10 * ^0.pi == 3.14... -- $TSa.greeting := HaloO; # mind the echo!
Re: type sigils redux, and new unary ^ operator
On Thu, Nov 24, 2005 at 12:08:44AM +0100, Stéphane Payrard wrote:
: What about array with holes as supported by Parrot?
We have prior art with hashes, but it's not clear how well that maps
across.
: Does .elems return the number of elements with or without
: the holes?
In Perl 5, non-existing array elements are still counted in size,
but non-existing hash elements are not.
And this is actually pointing to a distinction we have to make for
hashes and arrays that we don't have to make for ^5, because the
integers 0..4 always exist, whereas the keys of a hash or array come
and go. When we speak of the domain of a hash that is declared
my %hash{Str}
we could be confusing the signature Str with the current domain of
the mutating function, %hash.keys, which is presumably some subset
of Str, since Str represents an infinite set.
Put that together with use of 5 in a signature as a type. If you declare
my num %hash{5}
you may only index %hash with values that match the signature :(5).
The long form of that declaration is
my %hash :(5 -- num);
Where I was going with S9 is that we can't afford to make
my num @array[5;5;5]
a shortcut for
my @array :(0..4, 0..4, 0..4 -- Any)
because that confuses the use of 5 as an enumerated type value with
its use as a sizer. But the sizer notation is darn convenient, so
that's where
my num @array[^5;^5;^5]
came from. Assuming
my %hash{Str} = somevalues();
note the crucial distinction between
my %newhash{%hash.sig}
and
my %newhash{%hash.keys}
The latter produces a hash that may only be indexed by the *existing*
keys of %hash.
: Does iterating over the array iterates over the holes as well?
I'd say @array.keys should leave out the holes by analogy with hashes.
Presumably [EMAIL PROTECTED] would do the same.
Earlier I said that I thought .keys should just iterate the top
dimension, but I think that's probably wrong. Likely ,kv will most
naturally alternate key tuples and values, so I think .keys is also
returning key tuples, and we need some other notation for returning
the keys of the first index. .topkeys seems stupid, but I'm working
with a migraine today, so I'm stupid too. I feel like there's an
obvious solution, but I can't see it. Sigh.
In a sad twist of fate, you can't be as brilliant as you are some
of the time all of the time. :-)
: That would sound inefficient to do that over a mostly empty array.
True 'nuff. I think Juerd's question comes down to whether [EMAIL PROTECTED]
tracks existing elements or last element. I can see arguments for
both sides. The Perl 5 bias was that you should probably use the
hash interface if you have sparse data, and [EMAIL PROTECTED] tracks last
rather than [EMAIL PROTECTED] But then the implementation of arrays
in Perl 5 was such that non-existing elements still occupy an SV*
slot, so it kind of made sense from an efficiency point of view.
But it'd be kind of nice if @array went false when the last key
disappeared from a sparse array. But maybe [EMAIL PROTECTED] doesn't always
have to mean [EMAIL PROTECTED] == 0. Seems broken if not, though.
: Related question, Is there a way to get a list of iterators
: that iterate only over the non-holey parts of an array?
Not in Perl 5. I think .keys/^ should probably do that.
Larry
Re: type sigils redux, and new unary ^ operator
On Thu, Nov 24, 2005 at 12:42:25PM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-24 10:36 (+0100):
: it's about expression.
: Also if [EMAIL PROTECTED] is the multi-dimensional index zip?
:
: No.
:
: However, it does feel weird to have an *operator* that makes an array
: behave in a certain way. Well, not weird, because we're used to context,
: but operators usually don't carry their own dedicated context. I think a
: method would be a bit saner.
Hmm? No, nothing magical going on here, just MMD, insofar as ^
provides a scalar context, so @foo returns [EMAIL PROTECTED], and we can defined
operators however we like on a particular type according to MMD.
: I think that
:
: for @foo.indexes { ... }
:
: is a lot clearer, to everyone, than
:
: for [EMAIL PROTECTED] { ... }
:
: If .indexes turns out to be used a lot, then let's have .i -- i for
: index is accepted abbreviation, isn't it? (Think for (i = 0; ...;
: ...))
I think it's just .keys. And maybe .ix is the top level index. They'd
be synonymous for a single dimensional array or hash.
Larry
Re: type sigils redux, and new unary ^ operator
If .indexes turns out to be used a lot, then let's have .i -- i for index is accepted abbreviation, isn't it? (Think for (i = 0; ...; ...)) +1 here. I too find ^$n a bit bizarre, but I like the look of for @foo.i OTOH, I like the parallels between %foo.keys and @foo.keys -- it recalls the idea that an array can be thought of as a hash where the keys are constrained to be sequential (or not, if it is sparse) integers. -- Stop the infinite loop, I want to get off! http://surreal.istic.org/ Paraphernalia/Never hides your broken bones,/ And I don't know why you'd want to try:/ It's plain to see you're on your own.-- Paul Simon The documentation that can be written is not the true documentation.
directional ranges (was: Re: type sigils redux, and new unary ^ operator)
TSa: HaloO, Hi! Ruud H.G. van Tol: Yes, it could use a step: ^42.7 = (0, 7, 14, 21, 28, 35) ^42.-7 = (35, 28, 21, 14, 7, 0) OK, fine if the step sign indicates reversal after creation. That is, the modulus is 7 in both cases. ^-42.7 = (-35, -28, -21, -14, -7, 0) ^-42.-7 = (0, -7, -14, -21, -28, -35) I would make these ^-42.7 == (-42, -35, -28, -21, -14, -7) ^-42.-7 == ( -7, -14, -21, -28, -35, -42) No, that spoils it. The first number is not in the range. Written as -42.7^ it might have looked more familiar. and (^-42.7 + ^42.7) has length 11, maybe better expressed as ^-42.7.42, And the fact that you concatenate two six-element lists and get one with *11* elements doesn't strike you as odd? Not at all: they just overlap at 0. I find it very disturbing! E.g. when shifting by 42 rightwards I would expect ^-42.7.42 == (-42, -35, -28, -21, -14, -7, 0, 7, 14, 21, 28, 35) to become ^84.7 == (0, 7, 14, 21, 28, 35, 42, 49, 56, 63, 70, 77) and of course ^84.7 »- 42; or to more resemble your notation -42 +« ^84.7; beeing two other forms to write this kind. Ahh, and should there be a warning about a remainder for ^45.7 == (0, 7, 14, 21, 28, 35, 42) # rest 3 OK, a warning, but only at warning level 3 or more. Or maybe at 2, mental arithmetic isn't popular these days. (daughter in the background asks what's so funny) and how should a negative---err---endpoint be handled? I opt for ^-45.7 == (-49, -35, -28, -21, -14, -7) # rest 4 But the warning could be avoided with some dwimmery after we observe that 45 == 42 + 3 and -45 == -49 + 4 the respective rests mean to shift the list rightwards accordingly ^45.7 == (3, 10, 17, 24, 31, 38, 45)# shift right 3 ^-45.7 == (-46, -39, -30, -23, -18, -11, -4) # same ^-45.7 == (-45, -38, -31, -24, -17, -10, -3) # shift right 4 ^45.7 == (4, 11, 18, 25, 32, 39, 46)# same If you find the above odd, than use the homogenious cases ^45.7 == ( 3, 10, 17, 24, 31, 38, 45) # shift right 3 and ^-45.-7 == (-3, -10, -17, -24, -31, -38, -45) # reversed shift right -3 == -« ^45.7 which results in pairwise nullification as expected ^45.7 »+« ^-45.-7 == ^7.0 == (0,0,0,0,0,0,0) I hope those all resulted from the spoiling step, because I got lost. Let's switch to a shorter example list and use the , to build some subsets of int ^-21.7.0 , ^21.7.0 == (-21, -14, -7, 0, 7, 14) # length: 42/7 == 6 ^-21.7.1 , ^21.7.1 == (-20, -13, -6, 1, 8, 15) ^-21.7.2 , ^21.7.2 == (-19, -12, -5, 2, 9, 16) ^-21.7.3 , ^21.7.3 == (-18, -11, -4, 3, 10, 17) ^-21.7.4 , ^21.7.4 == (-17, -10, -3, 4, 11, 18) ^-21.7.5 , ^21.7.5 == (-16, -9, -2, 5, 12, 19) ^-21.7.6 , ^21.7.6 == (-15, -8, -1, 6, 13, 20) ^-21.7.7 , ^21.7.7 == (-14, -7, 0, 7, 14, 21) If the lists where extended on both sides to infinity then a shift of 7 changes anything, as can be seen from the last line. Hmm, the syntax is ambigous with respect to the . if we want to allow steps 1. No, that is invalid. But I had been thinking about a factor, like 1/5 for step 0.2. Looks like a jobs for the colon: ^21:7:0 == (0, 7, 14) ^1:0.25 == (0, 0.25, 0.5, 0.75) ^1:0.2:0.2 == (0.2, 0.4, 0.6, 0.8, 1.0) ^21.7 ^1./4 ^1./5 ^PI.22/7 == (0) which perhaps just mean ^1:step(0.2):shift(0.2) Please note that all of the above are *list literals* not prefix ^ operator invocations. If one wants to become variable in this type/kind then a @var is needed. A ^$x might be just a short form of capturing the kind of $x into ^x which not auto-listifies. Thus my ^x $x = 7; say ^x; # Int Nice: The domain of x is Int. say +$x; # 7 but my ^a @a = (0,0,0); say [EMAIL PROTECTED]; # 3 say ^a; # Array is shape(3) of Int # Array[^3] of Int # Array[ shape = 3, kind = Int ] or however the structure of an array is printed. which makes '^5' the short way to write '^5.1.0'. And ^0 is *the* empty list. Unintentional, but that's how many great things are found. Hmm, and ^Inf.0 the infinite list full of zeros (0, 0, 0, ...), ^Inf.1 are of course the non-negative integers in a list (0, 1, 2, ...). Then if we hyperate it and pick the last entry (^Inf.1 »+ 1)[-1] we get the first transfinite ordinal Omega[0]. From there we keep counting transfinitely... I suddenly feel whole again. And of course 10 * ^0.pi == 3.14... And that's what we all do things for. -- Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
On 11/23/05, Rob Kinyon [EMAIL PROTECTED] wrote:
On 11/22/05, Larry Wall [EMAIL PROTECTED] wrote:
for ^5 { say } # 0, 1, 2, 3, 4
I read this and I'm trying to figure out why P6 needs a unary operator
for something that is an additional character written the more legible
way.
Huh? Are you saying that 0..^5 is one more character than ^5?
In any case, I'm not sure that this unary helps readability, or that I
like it all that much, but I can say that it's damned useful. I use
ranges of the form 0..$n-1 more than any other range, by a very long
shot.
To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand.
Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
So it seems that ^$x should be one($x). But that's an entirely
useless, trivial junction, so it makes sense to steal the syntax for
something else.
Luke
implied looping (was: Re: type sigils redux, and new unary ^ operator)
Larry Wall:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
c. (0..4) { say; say }
d. @{0..4} { say; say }
(etc.)
b. now produces 2 lines with 01234 (in pugs). With implied looping that
would be 10 lines, starting with two 0-lines.
--
Grtz, Ruud
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
On Wed, 23 Nov 2005, Ruud H.G. van Tol wrote:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
I'm not really sure: while I like it for its conciseness -and in
particular I've often desired a very short, but clear, way to say: do
this #n times- IIUC (Perl6 new rules for blocks/closures and
dereferencing) this is only one dot or even whitespace away from passing a
list into an anonymous sub. Which may be confusing after all...
The problem (if any!) does not persist for the postponed block form. But
as far as code like
^5 { do_it };
is concerned, it is even _too_ concise, and I'd prefer some additional
syntactical indication about what's going on. For my tastes,
^5: { do_it }; # But then also 5: { do_it }; [*]
would be perfect, were not the colon already taken for a bazillion other
uses...
OTOH if I remember correctly there should be (provision for) a Cxx
variant that takes a closure and executes it over and over again.
[*] Or 5 - { do_it }; but I strongly suspect this would interfere with
pointy subs.
Michele
--
I am a deeply religious nonbeliever.
This is a somewhat new kind of religion.
- Albert Einstein
Re: type sigils redux, and new unary ^ operator
Luke~
On 11/23/05, Luke Palmer [EMAIL PROTECTED] wrote:
On 11/23/05, Rob Kinyon [EMAIL PROTECTED] wrote:
On 11/22/05, Larry Wall [EMAIL PROTECTED] wrote:
for ^5 { say } # 0, 1, 2, 3, 4
I read this and I'm trying to figure out why P6 needs a unary operator
for something that is an additional character written the more legible
way.
Huh? Are you saying that 0..^5 is one more character than ^5?
In any case, I'm not sure that this unary helps readability, or that I
like it all that much, but I can say that it's damned useful. I use
ranges of the form 0..$n-1 more than any other range, by a very long
shot.
To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand.
Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
So it seems that ^$x should be one($x). But that's an entirely
useless, trivial junction, so it makes sense to steal the syntax for
something else.
I think using C ..5 to mean (0, 1, 2, 3, 4) would be a more
sensible option. Makes sense to me at least.
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: type sigils redux, and new unary ^ operator
Rob Kinyon skribis 2005-11-23 11:58 (-0500): I don't use 0..$n-1 very often. I use 0..$#arr most often. Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we should write what we mean, instead of something that happens to evaluate to the same list. We mean to use indexes, but [EMAIL PROTECTED] doesn't return an index. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
On Wed, Nov 23, 2005 at 02:23:51PM +0100, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: for ^5 { say } # 0, 1, 2, 3, 4
:
: The 'for' can go if a list (and also an array) would imply looping, when
: it is positioned next to a block:
:
: a. say (0..4);
: b. { say; say } (0..4);
: c. (0..4) { say; say }
: d. @{0..4} { say; say }
: (etc.)
:
: b. now produces 2 lines with 01234 (in pugs).
Which is wrong by the current spec, by the way. It should be a syntax
error to have two terms in a row. Bare parens can't be function args
unless they're abutted or use ..
: With implied looping that would be 10 lines, starting with two 0-lines.
I don't like that much deep magic without a keyword to clue the reader,
and we have plenty of keywords to work it already:
for ^5 { say }
^5.each { say }
(0..4).each == say
say for ^5;
I can see the mathematical appeal of coming up with a language in
which there is a meaning for every possible combination of tokens.
But there's an important linguistic principle here that I think has
never been adequately researched, and is probably worth a doctorate
to whoever does it. But it's a subtle principle, so it's rarely
mentioned. That principle is that there has to be some kind of
self-clocking aspect to a syntax, or you never realize if you've
gotten out of sync. In other words, there have to be some sequences
in the syntax that are syntax errors, or you'll never get any syntax
errors. That sounds like a tautalogy, but I don't mean it that way.
The self-clocking, phase-locked-loop aspect of Perl is driven by the
fact that we almost never allow two terms in a row, and also by the
fact that it's pretty easy to distinguish terms from operators most
of the time. This is what allows Perl to be a language that does,
in fact, overload leading characters between terms and operators
rather heavily. But if we allowed you to say $foo %bar and gave
it some meaning, you wouldn't be able to tell whether that % should
be a sigil or a modules operator.
And we also have to be careful about terms like {...} and (...) and
[...]. We've already made the exception that you can have {...} where
an operator is expected--that's exactly how the grammar recognizes
the difference between
for foo 1,2,3 {...}
and
for foo 1,2,3,{...},{...},{...} {...}
But it's easy enough to get tangled up with that exception, and if we
start making any sequence of bare brackets mean something, we'll not
get a syntax error but an unexpected successful parse, which can be
far more devastating than a syntax error.
However, in order to milk our bracketing characters for all they're
worth, as well as all the other operators, we finessed it in Perl 6
depending on the whitespace (or .) so that we can tell which
operators are intended as postfix operators and which ones are
misplaced terms. And that's why
{say} (1)
has to be a syntax error, while
{say}(1)
{say}.(1)
are just function calls. We really have to make that rule, or people
will be very confused a very large amount of the time. And the worst
part of it is that they'll think it's because they're stupid, not
because the language is poorly designed. It's a counterintuitive fact
that languages that are too efficiently coded induce inefficiencies in
communication. We're already dancing on the brink of too efficient,
and it would be easy to fall over the edge. Some would say we already
have...
Larry
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
Larry Wall skribis 2005-11-23 9:19 (-0800):
^5.each { say }
Without colon?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 11:58:23AM -0500, Rob Kinyon wrote: : Here's an issue - if ^$x would be one($x), then what will [EMAIL PROTECTED] be? To : me, that seems like it should be one(@x), which is entirely useful. : Except, if I try and use it as [EMAIL PROTECTED] (which, to me, would be useful). : So, now, is it 0..one(@x) or [EMAIL PROTECTED] It's the latter, regardless of whether you visually parse it as 0 .. [EMAIL PROTECTED] 0 ..^ @x Perl parses it the latter way, of course, but the visual pun is part of why I wanted ^ to be short for 0..^. Larry
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote: : I think using C ..5 to mean (0, 1, 2, 3, 4) would be a more : sensible option. Makes sense to me at least. That doesn't derive well from any of: .. ^.. ..^ ^..^ If the rule is you can omit the 0, then it's ..^5 rather than ..5. Larry
Re: type sigils redux, and new unary ^ operator
Juerd:
Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
Maybe someone doing
for ([EMAIL PROTECTED])-$i { say @foo[$i] }
in stead of
say for @foo
After all, we should
write what we mean, instead of something that happens
to evaluate to the same list.
I read ^5 as a range-list, like (in some mathematical notation) [0..5
or [0..4].
Such a list can be stored as (start;count;step=1).
Yes, it could use a step:
^42.7 = (0, 7, 14, 21, 28, 35)
^42.-7 = (35, 28, 21, 14, 7, 0)
^-42.7 = (-35, -28, -21, -14, -7, 0)
^-42.-7 = (0, -7, -14, -21, -28, -35)
and (^-42.7 + ^42.7) has length 11, maybe better expressed as ^-42.7.42,
which makes '^5' the short way to write '^5.1.0'.
--
Grtz, Ruud
Re: type sigils redux, and new unary ^ operator
Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
Doesn't ^5 encourage [EMAIL PROTECTED] too much?
Can you explain when that creates a problem?
It's not about problems in execution, it's about expression.
[EMAIL PROTECTED] returns the *number of elements*, not the index of the last
element plus one. It should not be used for index math.
There are cases where we should write @foo.last + 1, even though the
result will in almost all cases be the same as [EMAIL PROTECTED], and there are
cases where we should write @foo - 1, even though the result will be the
same as that of @foo.last.
That almost all arrays range from 0..i is no reason to write bad code.
Maybe someone doing
for ([EMAIL PROTECTED])-$i { say @foo[$i] }
That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
latter.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
: Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
: Doesn't ^5 encourage [EMAIL PROTECTED] too much?
: Can you explain when that creates a problem?
:
: It's not about problems in execution, it's about expression.
:
: [EMAIL PROTECTED] returns the *number of elements*, not the index of the last
: element plus one. It should not be used for index math.
:
: There are cases where we should write @foo.last + 1, even though the
: result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
: cases where we should write @foo - 1, even though the result will be the
: same as that of @foo.last.
:
: That almost all arrays range from 0..i is no reason to write bad code.
:
: Maybe someone doing
:for ([EMAIL PROTECTED])-$i { say @foo[$i] }
:
: That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
: latter.
I don't think that's a big problem. Formal arrays are allowed to view
all incoming array parameters as 0-based even if created elsewhere as
non-0-based arrays. Forcing everyone to use the same circumlocutions
because someone somewhere *might* use a non-0-based view of their
arrays is just falling back into one of those magical action at a
distance traps, I think. A non-0-based view is fine in a particular
lexical scope, but it shouldn't leak out.
Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
scope.
Larry
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 10:45:21AM -0800, Mark A. Biggar wrote: : Actually I like that and think that ^$x should be 0..($x-1) and that : [EMAIL PROTECTED] should be define to return the array's index set (usually : 0..$#foo) but maybe something else for a non-zero based array. Well, as I said in my other reply, that's not a big problem for 1-dimensional arrays. But it does possibly make sense that ^ on a multidimensional array or hash would return a zip of all the key sets. Plus it generalizes ^%hash to mean %hash.keys. Flipping it the other way, does that argue that 5.keys means 0..4? Hmm. Doesn't do much for me. One of the other reasons I like ^5 is that the uparrowness of it naturally reads as up to 5. But for containers we could certainly abstract it out to the domain. Larry
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 10:58:53AM -0800, Larry Wall wrote: : Well, as I said in my other reply, that's not a big problem for : 1-dimensional arrays. But it does possibly make sense that ^ on a : multidimensional array or hash would return a zip of all the key sets. : Plus it generalizes ^%hash to mean %hash.keys. Or maybe not. We need some way of getting the keys of just the first dimension, and maybe .keys is that, on the model of Perl 5, where all multidims are really XoX in form, and .keys only ever gives you the top level. Then ^%hash and %hash.keys would mean the same thing only for 1-dimensional hashes. Likewise for arrays. Larry
Re: type sigils redux, and new unary ^ operator
Larry~ On 11/23/05, Larry Wall [EMAIL PROTECTED] wrote: On Wed, Nov 23, 2005 at 11:55:35AM -0500, Matt Fowles wrote: : I think using C ..5 to mean (0, 1, 2, 3, 4) would be a more : sensible option. Makes sense to me at least. That doesn't derive well from any of: .. ^.. ..^ ^..^ If the rule is you can omit the 0, then it's ..^5 rather than ..5. I like C ..^5 better than C ^5 actually. I was going for the rule that an omitted LHS was 0 and an omitted RHS was infinity (your probably cannot omit both). Regardless, my gut tells me that C ^5 is just a little too short for what it does. Also, I find the argument that people will type [EMAIL PROTECTED] and get confused fairly convincing. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: type sigils redux, and new unary ^ operator
LW == Larry Wall [EMAIL PROTECTED] writes: LW One of the other reasons I like ^5 is that the uparrowness of it LW naturally reads as up to 5. But for containers we could certainly LW abstract it out to the domain. it also harkens back to apl's iota op which did similar things. iota is an integer range generation operator which returned 1 .. N in monadic (prefix) mode and M .. N in dynadic (infix) mode. and ^ used to be a full up arrow with a shaft (teletypes) and that is vaguely similar to the iota char. but given larry's stretchable imagination i don't think this mnemonic would hurt anyone. you just need to know some computer history. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 02:21:15PM -0500, Matt Fowles wrote: : I like C ..^5 better than C ^5 actually. I was going for the : rule that an omitted LHS was 0 and an omitted RHS was infinity (your : probably cannot omit both). But that only saves you 1 keystroke, and eliminates unary .. for any other use. : Regardless, my gut tells me that C ^5 is just a little too short : for what it does. I'd've felt the same way before I started revising S9, whereupon I discovered I wanted ^5 all over the place. It was either that or make special exceptions for lists containing one element, and that was gross. : Also, I find the argument that people will type : [EMAIL PROTECTED] and get confused fairly convincing. I dunno. I'm not confused by it, and I'm easily confused. Or maybe I'm just confused about not being confused... Larry
Re: type sigils redux, and new unary ^ operator
On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
What tipped me over the edge, however, is that I want ^$x back for a unary
operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
kept wanting such an operator in revising S09. It also makes it easy to
write
for ^5 { say } # 0, 1, 2, 3, 4
It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
I'm also puzzled that you feel the need to write 0..$n-1 so often; there
are so many alternatives to fenceposting in P5 that I almost never write
an expression like that, so why is it cropping up that much in P6?
--
Peter Scott
Re: type sigils redux, and new unary ^ operator
On Wed, Nov 23, 2005 at 08:04:32AM -0800, Peter Scott wrote:
: On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
: What tipped me over the edge, however, is that I want ^$x back for a unary
: operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
: kept wanting such an operator in revising S09. It also makes it easy to
: write
:
: for ^5 { say } # 0, 1, 2, 3, 4
:
: It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
But then you'd usually want 1..$n instead...
: I'm also puzzled that you feel the need to write 0..$n-1 so often; there
: are so many alternatives to fenceposting in P5 that I almost never write
: an expression like that, so why is it cropping up that much in P6?
Couple reasons occur to me offhand. First we're doing away with $#foo.
Second is all the array sizing in P5 is implicit, whereas S9 style
arrays are all about explicit array sizing, and 0..$n-1 comes up all
the time there. But I also am liking the generalization of unary ^
to mean domain.
And in an axiomatic sort of way, it corresponds to those theories
of math that build up the integers by counting set elements. The
argument that produces 5 is 0..4. And it works out that +^5 == 5.
But the generalization to hashes is even cooler because I can say
my %thishash{^%thathash};
or some such to duplicate the shape regardless of the typology
of %thathash.
Larry
Re: type sigils redux, and new unary ^ operator
Larry Wall a écrit :
| On Wed, Nov 23, 2005 at 07:10:39PM +0100, Juerd wrote:
| : Ruud H.G. van Tol skribis 2005-11-23 19:03 (+0100):
| : Doesn't ^5 encourage [EMAIL PROTECTED] too much?
| : Can you explain when that creates a problem?
| :
| : It's not about problems in execution, it's about expression.
| :
| : [EMAIL PROTECTED] returns the *number of elements*, not the index of the
last
| : element plus one. It should not be used for index math.
| :
| : There are cases where we should write @foo.last + 1, even though the
| : result will in almost all cases be the same as [EMAIL PROTECTED], and there
are
| : cases where we should write @foo - 1, even though the result will be the
| : same as that of @foo.last.
| :
| : That almost all arrays range from 0..i is no reason to write bad code.
| :
| : Maybe someone doing
| :for ([EMAIL PROTECTED])-$i { say @foo[$i] }
| :
| : That should be ^(@foo.last + 1), or not using ^ at all. I'd prefer the
| : latter.
|
| I don't think that's a big problem. Formal arrays are allowed to view
| all incoming array parameters as 0-based even if created elsewhere as
| non-0-based arrays. Forcing everyone to use the same circumlocutions
| because someone somewhere *might* use a non-0-based view of their
| arrays is just falling back into one of those magical action at a
| distance traps, I think. A non-0-based view is fine in a particular
| lexical scope, but it shouldn't leak out.
|
| Which means you can use [EMAIL PROTECTED] and know it's right in your lexical
| scope.
What about array with holes as supported by Parrot?
Does .elems return the number of elements with or without
the holes?
Does iterating over the array iterates over the holes as well?
That would sound inefficient to do that over a mostly empty array.
Related question, Is there a way to get a list of iterators
that iterate only over the non-holey parts of an array?
--
cognominal stef
|
| Larry
|
Re: type sigils redux, and new unary ^ operator
Larry Wall skribis 2005-11-23 13:10 (-0800): : It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n. But then you'd usually want 1..$n instead... I think this illustrates very well that it's a bit silly to have a shortcut for just one of the three much-used ranges. My view is that this shortcut hurts clarity. It's almost as if a purpose was sought for the available ^, rather than there is something that will be used a lot, that needs a shortcut. Personally, I think even ^.., ^..^ and ..^ are too much, but that I can live with. Couple reasons occur to me offhand. First we're doing away with $#foo. Yea, and there's @foo.last to replace it. Indexes and numbers (counts) just aren't the same thing, and I think source code should communicate meaning using the right words. The word for the last index is .last, that of the number of elements is .elems, or [EMAIL PROTECTED] If you need the last index, plus one, you shouldn't use the number of elements, and if you need the number of elements, minus one, you shouldn't use the last index. Am I the only one who cares about this distinction? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
Juerd skribis 2005-11-24 0:39 (+0100): Personally, I think even ^.., ^..^ and ..^ are too much, but that I can live with. For the record, I don't want to die if ^ is introduced. If it's there, I'll use it. If using [EMAIL PROTECTED] becomes accepted style, I'll use it. The live with isn't to be interpreted implying anything :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: type sigils redux, and new unary ^ operator
On 11/23/05, Larry Wall [EMAIL PROTECTED] wrote:
: I'm also puzzled that you feel the need to write 0..$n-1 so often; there
: are so many alternatives to fenceposting in P5 that I almost never write
: an expression like that, so why is it cropping up that much in P6?
Couple reasons occur to me offhand. First we're doing away with $#foo.
Second is all the array sizing in P5 is implicit, whereas S9 style
arrays are all about explicit array sizing, and 0..$n-1 comes up all
the time there. But I also am liking the generalization of unary ^
to mean domain.
What about @array.indices instead? Then, there's no possible
fenceposting, your code is self-documenting, and we're not introducing
another unary operator?
And in an axiomatic sort of way, it corresponds to those theories
of math that build up the integers by counting set elements. The
argument that produces 5 is 0..4. And it works out that +^5 == 5.
So, +^5 is the way to generate the Church number for 5 through the use
of an iterator masquerading as a range?
But the generalization to hashes is even cooler because I can say
my %thishash{^%thathash};
or some such to duplicate the shape regardless of the typology
of %thathash.
my %thishash{%thathash.keys};
Much easier to read. The methods are there for a reason. Don't re-add
operators where there's a perfectly good method. Plus, overwriting
methods is much easier to grok for the average programmer than the
corresponding operator, unless you're aliasing the operator, in which
case I have problems figuring out why this is good, unless we're
deliberately designing P6 for the obfu/golf crowd.
Re: type sigils redux, and new unary ^ operator
On 11/22/05, Larry Wall [EMAIL PROTECTED] wrote:
What tipped me over the edge, however, is that I want ^$x back for a
unary operator that is short for 0..^$x, that is, the range from 0
to $x - 1. I kept wanting such an operator in revising S09. It also
makes it easy to write
for ^5 { say } # 0, 1, 2, 3, 4
I read this and I'm trying to figure out why P6 needs a unary operator
for something that is an additional character written the more legible
way. To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand. So, ^0 would be -1 (under 2's complement) and ^1 would
be -2. I'm not sure where this would be useful, but that's what comes
to mind when discussing a unary ^.
Thanks,
Rob
