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
On Fri, Nov 25, 2005 at 01:06:43AM +0100, Leopold Toetsch wrote:
> Likely due to the stricter label checking we have these test failures
> now:
>
> Failed Test Stat Wstat Total Fail Failed List
> of Failed
> --
On Wed, Nov 23, 2005 at 03:08:31PM -0800, jerry gay wrote:
> # New Ticket Created by jerry gay
> # Please include the string: [perl #37745]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=37745 >
>
>
> test 502 causes p
Likely due to the stricter label checking we have these test failures
now:
Failed Test Stat Wstat Total Fail Failed List
of Failed
---
t/compilers/pge/p5regexp/p5rx.t 2 512 8002
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)
I'm currently fixing #37590 and removed tons of code from imcc/pbc.c.
The changes are causing a more strict error checking WRT label usage
and a slight restriction WRT labels in PASM code:
.pcc_sub foo:
...
branch foo
is now illegal. In practice there is probably always a get_params after
> 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
# New Ticket Created by "Ruud H.G. van Tol"
# Please include the string: [perl #37754]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37754 >
<[EMAIL PROTECTED]>
Ruud wrote:
> b. { say; say } (0..4);
>
> b. now produces
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?
>>
jerry gay (via RT) wrote:
test 502 causes parrot to eat all memory and use all cpu (on win32 anyway.)
since i've added a special env var to support the running of a single
test in this test file, it can be run in isolation like:
set TEST_P5RX=502
prove t/compilers/pge/p5regexp/p5rx_1.pir
b
# New Ticket Created by jerry gay
# Please include the string: [perl #37745]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37745 >
test 502 causes parrot to eat all memory and use all cpu (on win32 anyway.)
since i've ad
23 matches
Mail list logo
