[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 worth
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply Cconvert:as(..., ::int) 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
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 desired
--- 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 actually run
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
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
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];
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]
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 hash
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 {
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
Stphane 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 to mean
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 the
-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.
Perl 6
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: 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]);
Which
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:
++ [EMAIL
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 lvalues.
:
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, %h); #
Luke asked:
Er, did the hyper operator's direction flip? I thought it was:
++ [EMAIL PROTECTED];
My bad. 'Tis indeed.
Damian
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
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); cmpthese -1, { a =
22 matches
Mail list logo
