I'd like to add a few more cases:
(1, $a)[0] = 42; # dies ?
(1, $a)[0] := 42; # dies ?
(1, $a)[1] = 42; # modify $a ?
(1, $a)[1] := 42; # makes $a constant ?
Ingo Blechschmidt wrote:
> (These questions were motivated by Flavio's work in progress [2] ("A
> draft on the runtim
Hello all,
I get the impression that hyperoperators are finalized. Nevertheless,
here's an alternative way of hyperoperating on arrays. It uses
superscript numbers to indication index iteration. It allows terse
syntax for reversing arrays, getting the dot product, and even doing a
matrix mult
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)
> 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
t
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
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 ar
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
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 ee
Hi,
my ($a, $b, $c) = ;
my $also_a := ($a,$b,$c)[0];
$also_a eq "a"; # correct?
$also_a = "A"; # does not die?
$a eq "A"; # true?
my $also_b = "b";
($a,$b,$c)[1] := $also_b;
$b eq "b"; # true?
$b = "B";# does not die?
$also_b eq
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] m
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?
++
Jue
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] re
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 ope
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.
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 cha
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?
>>
16 matches
Mail list logo