Uri Guttman skribis 2004-05-19 0:08 (-0400):
> J> 1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
> J> 1..10); cmpthese -1, { a => sub { my %foo; $foo{$_}++ for @foo; }, i
> J> b => sub { my %foo; $_++ for @[EMAIL PROTECTED]; } }'
> J> Rate a
> "J" == Juerd <[EMAIL PROTECTED]> writes:
J> John Williams skribis 2004-05-18 16:07 (-0600):
>> >$a{$_}++ for @a;
>> [EMAIL PROTECTED];
J> That's not a bad idea, even in Perl 5:
J> 1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
J> 1..10); cm
Austin Hastings asked:
Junctions are value, not lvalues.
Why not bundle lvalues together?
Because, although this would mean what it says:
all($x, $y, $z)++;
None of these would:
any($x, $y, $z)++;
one($x, $y, $z)++;
none($x, $y, $z)++;
We're trying to avoid intr
Luke asked:
Er, did the hyper operator's direction flip? I thought it was:
++Â [EMAIL PROTECTED];
My bad. 'Tis indeed.
Damian
On Tue, May 18, 2004 at 11:14:30PM +0200, Stéphane Payrard wrote:
> I thought overloading the += operator
>
>%a += @a;
There's been lots of discussion of this, but:
> Probably that operator should be smart enough to be fed with
> a mixed list of array and hashes as well:
>
> %a += ( @a, %
On Tue, May 18, 2004 at 06:32:28PM -0600, Luke Palmer wrote:
: Damian Conway writes:
: > Austin Hastings wrote:
: >
: > >Hmm. For junctions I was thinking:
: > >
: > > ++ all([EMAIL PROTECTED]);
: > >
: > >Which is almost readable.
: >
: > But unfortunately not correct. Junctions are value, not
Damian Conway writes:
> Austin Hastings wrote:
>
> >Hmm. For junctions I was thinking:
> >
> > ++ all([EMAIL PROTECTED]);
> >
> >Which is almost readable.
>
> But unfortunately not correct. Junctions are value, not lvalues.
>
> This situation is exactly what hyperoperators are for:
>
> ++Â
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 18 May, 2004 08:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: idiom for filling a counting hash
>
>
> Austin Hastings wrote:
>
> > Hmm. For junctions I was thinking:
> >
> > ++ all([EMAIL PROTECTED]
Austin Hastings wrote:
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which is almost readable.
But unfortunately not correct. Junctions are value, not lvalues.
This situation is exactly what hyperoperators are for:
++Â [EMAIL PROTECTED];
Damian
> -Original Message-
> From: Luke Palmer
> %a Â+Â= @a;
> Is the operator you want. But, after all that,
>
> ++Â [EMAIL PROTECTED]
>
> Was probably the best way to do it all along.
>
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which is almost readable.
On Tue, 2004-05-18 at 18:16, Juerd wrote:
> St?phane Payrard skribis 2004-05-18 23:14 (+0200):
> > I use over and over this idiom in perl5:
> >$a{$_}++ for @a;
> > This is nice and perlish but it gets easily pretty boring
> > when dealing with many list/arrays and counting hashes.
I never saw
StÃphane Payrard writes:
> I use over and over this idiom in perl5:
>
>$a{$_}++ for @a;
>
> This is nice and perlish but it gets easily pretty boring
> when dealing with many list/arrays and counting hashes.
>
> I thought overloading the += operator
>
>%a += @a;
Though that would like
On Tue, 2004-05-18 at 05:23, James Mastros wrote:
> (Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
> the syntax changed, or is he wrong?)
Aaron Sherman was arm-waving as the important bits were not related to
the specific syntax of coerce overloading.
--
Aaron Sherman
John Williams skribis 2004-05-18 16:07 (-0600):
> >$a{$_}++ for @a;
> [EMAIL PROTECTED];
That's not a bad idea, even in Perl 5:
1;0 [EMAIL PROTECTED]:~$ perl -MBenchmark=cmpthese -e'my @foo = (1..16,
1..10); cmpthese -1, { a => sub { my %foo; $foo{$_}++ for @foo; }, i
b => sub
St?phane Payrard skribis 2004-05-18 23:14 (+0200):
> I use over and over this idiom in perl5:
>$a{$_}++ for @a;
> This is nice and perlish but it gets easily pretty boring
> when dealing with many list/arrays and counting hashes.
A3 says something about tr being able to return a histogram (a h
> "JW" == John Williams <[EMAIL PROTECTED]> writes:
JW> On Tue, 18 May 2004, Stéphane Payrard wrote:
>> I use over and over this idiom in perl5:
>>
>> $a{$_}++ for @a;
JW> [EMAIL PROTECTED];
i see dead languages (apl :)
uri
--
Uri Guttman -- [EMAIL PROTECTED] ---
On Tue, 18 May 2004, Stéphane Payrard wrote:
> I use over and over this idiom in perl5:
>
>$a{$_}++ for @a;
>
In perl6, using a hash slice and a hyper(increment)operator:
[EMAIL PROTECTED];
On Mon, 2004-05-17 at 17:13, chromatic wrote:
> As Luke suggests, there's also programmer clarity to consider. If
> determining how to compare depends on how you've used the variables to
> compare, is it harder to understand the code?
To be specific, what does:
my $a = foo();
my
I use over and over this idiom in perl5:
$a{$_}++ for @a;
This is nice and perlish but it gets easily pretty boring
when dealing with many list/arrays and counting hashes.
I thought overloading the += operator
%a += @a;
Probably that operator should be smart enough to be fed with
a mixed
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> People were talking about what type "..." should be. So at static
> type analysis time (if we even do that; I think we do, otherwise we
> wouldn't have static type declarations), you give "..." type error
> semantics, but then don't die until you actu
James Mastros writes:
> >In the case of ..., give it type error semantics. That is, any
> >expression involving ... gets type "...". Except instead of reporting
> >at the end of the statement, just suppress the errors and move on.
>
> Huh? Um, no, your ideas as to what happens don't give the de
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply C and fail at run-time,
correct? There's nothing wrong with TRYING to do the conversion, just as
there should not be anything wrong with:
my int $i = "4";
which has some pretty simple s
[EMAIL PROTECTED] (Chromatic) writes:
> Is "10" a string? Is it a number? Is "10base-T" a string? Is it a
> number? Is an object with overloaded stringification and numification a
> number? Is it a string?
>
> I don't know a good heuristic for solving these problems. If you have
> one, it's
23 matches
Mail list logo
