Re: RFC eq and ==
[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 considering though. Use =~ for all these kinds of comparison. No, I'm not being facetious, at least not intentionally. -- At Friday's meeting I did get a chance to call a spade an earth-moving bloody implement of damn-and-blasted wood and bastard metal construction. - Red Drag Diva
Re: Yadda yadda yadda some more
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 some pretty simple semantics in Perl.
Right. Though, constant folding at CHECK time might be able to tell when
you're *going* to do an invalid conversion and complain about it right
then.
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
semantics for ..., and don't make other desired semantics fall out
naturally.
The basic semantic for ... is that use of it gives an error at runtime,
when the code has been hit. Unless a pragmata changes things, it
should not be possible to trigger an error from use of ... without the
code being actually run.
Thus, I propose the following: A convert routine should be able to tell
if it's being run at runtime or compile time, and do a fail with reason
matching :i/not yet/ or :i/too early/, to defer the conversion until
runtime.
This gives the desired semantics for ... -- an error at runtime, not
compile time. It also allows for desired semantics elsewhere. Say I
have two classes, Net::IP::Addr and Net::HostName. It should be
possible to convert a Net::HostName to a Net::IP::Addr, but that
conversion should not happen until runtime (because I may be keeping
around the bytecode for a long time, and the hostname-IP mapping may be
different by then).
(Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
the syntax changed, or is he wrong?)
multi sub *coerce:as (Net::HostName $name, Net::IP::Addr ::to) {
fail 'Too early to convert hostname to IP address' if
(we_are_in_compile_time);
$name.lookup;
}
(Yes, I know those parens around the condition of the if are optional --
even in perl5. I like them.)
What I don't know is how to write Cwe_are_in_compile_time. A property
of the object that Ccaller gives?
I don't really like using fail with regex matching here, but we need to
be able to return a real undef (we don't mind converting early, but the
correct conversion is to undef -- C0 as bool), should be able to
really fail (it's not a valid conversion, and waiting won't help
anything -- Csqrt(-1) as Real).
BTW, since that example above isn't the hottest, imagine defining a
conversion from a hostname to a DNS lookup, that saves the expiry time,
and defining a second coercion from that to an IP address, that reruns
the lookup if the TTL has expired. The first coercion should take place
at compile time, the second not until runtime.
-=- James Mastros
Re: Yadda yadda yadda some more
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 semantics for ..., and don't make other desired semantics fall out naturally. The basic semantic for ... is that use of it gives an error at runtime, when the code has been hit. Unless a pragmata changes things, it should not be possible to trigger an error from use of ... without the code being actually run. 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 the my int $foo = ...; # ... my int $bar = 34;# int $bar += $foo;# ... That's the correct solution to the type analysis problems. I wasn't trying to address anything else. The problem was that people were trying to derive it/make it a role/give it some type that could go anywhere. I'm just saying it should be a special case. That special case is already used when there's a type error, except that the type error dies after the current statement finishes processing. Luke
Re: Yadda yadda yadda some more
--- 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 the
my int $foo = ...; # ...
my int $bar = 34;# int
$bar += $foo;# ...
That's the correct solution to the type analysis problems. I wasn't
trying to address anything else.
The problem was that people were trying to derive it/make it a
role/give it some type that could go anywhere. I'm just saying it
should be a special case. That special case is already used when
there's a type error, except that the type error dies after the
current statement finishes processing.
How do I extend ...?
That is, I want to code \U{VERTICAL ELLIPSIS} as a code goes here
alternative to ... with some additional semantics.
So, how wrong is this:
class VerticalYadda
{
extends Yadda;
multi method coerce:as($what) {
say Coercing VerticalYadda to ~ ($what as Str);
next METHOD;
}
}
sub *\U{VERTICAL ELLIPSIS}()
{
return new VerticalYadda;
}
=Austin
idiom for filling a counting hash
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 list of array and hashes as well:
%a += ( @a, %h); # would mean %a += ( @a, keys %h)
I am not to sure how one can use hyperators, well I meant the
hyped hyperoperators, to juggle with lists and counting hashes.
One may want to feed multiple arrays to a single hash or one
array to multiple hashes. To add some salt to the problem
Multiple can translate to an array of :
my @ary_of_h of Hash; @ary_of_h += @a;
Having real types in Perl6 will allow to slice, dice, splice data
in many nice ways. Damian can even spice that with junctions.
Fear. Fear.
--
stef
Re: RFC eq and ==
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 $b = bar();
if $a == $b {
baz();
}
mean? Is it a numeric comparison? String? What?
The reason we need == and eq is to allow the programmer to specify which
behavior they wish. It really is that simple.
Now, that brings us to an ugly little bridge for higher level objects,
of course. What does it mean to override infix:== or infix:eq and which
would you override when?
It's going to have to be a matter of convention, but I would suggest
that things which feel numeric should provide an == and things that
feel stringy should provide an eq, but not both unless they are
actually different in some relatively obvious way to the casual Perl
programmer.
That means that while a matrix class might define ==, it probably should
not defined eq (though it might be serializable in some way that makes
eq possible through conversion). Similarly, a class that represents a
DNS zone should probably provide an eq, but not ==.
All that make sense?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: idiom for filling a counting hash
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];
Re: idiom for filling a counting hash
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] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Re: idiom for filling a counting hash
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 like
your %a), A5 says something about tr being able to match more than just
characters.
There must be some neat trick with tr that you can use for this :)
But maybe it's better to just define a histogram method for arrays. Then
you can get the unique elements by doing @array.histogram.keys. But
again, just having a method for that is probably a better idea (if only
because with the hash, the original order is lost).
Juerd
Re: idiom for filling a counting 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 { my %foo; $_++ for @[EMAIL PROTECTED]; } }'
Rate a b
a 51121/s -- -9%
b 56220/s 10% --
Juerd
Re: Yadda yadda yadda some more
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 [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: idiom for filling a counting hash
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 that:
%a + @a
Is %a with each of @a incremented. Which is quite nonsense, since it's
the number of keys of %a plus the number of values of @a.
Obviously adding to a hash means nothing, so there's no ambiguity with
using +=, but it's that disagreement that makes me uneasy.
But if you must, I believe it's possible:
multi sub *infix:+= (%hash is rw, $scalar) is rw {
++%hash{$scalar}; %hash;
}
multi sub *infix:+= (%hash is rw, @array) is rw {
++ [EMAIL PROTECTED]; %hash;
}
[snip]
Having real types in Perl6 will allow to slice, dice, splice data
in many nice ways. Damian can even spice that with junctions.
Fear. Fear.
Yeah, junctions fit the purpose better, unless you're histogramming.
Or better yet, since Junctions can only be in scalar variables, one
might use | to mean hash union.
my %a := { a = 1, b = 2 };
my %b := { b = 3, c = 4 };
%a | %b;#{ a = 1, b = 2, c = 4 }
And what's better, adverbial modifiers will allow us to give a key union
sub:
%a | %b :union{ $^a + $^b } # { a = 1, b = 5, c = 4 }
Or you could go APL and make another meta-operator:
multi sub *infix_circumfix_meta_operator:... ($op) {
sub (%a, %b) {
%a | %b :union{ $op($^x, $^y) }
}
}
So you get:
%a + %b; # { a = 1, b = 5, c = 4 }
And then:
%a += @a;
Is the operator you want. But, after all that,
++ [EMAIL PROTECTED]
Was probably the best way to do it all along.
Perl 6 frightens me. I love it.
Luke
Re: idiom for filling a counting hash
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, but in Perl 5, you would probably just define
a class which stored the information you needed. In Perl 6, it should be
much easier to make that class behave the way you want syntactically,
but for example in Perl 5 (wrap with tie to taste):
package CountedArray;
sub new { $obj=bless {}, $_[0]; $obj-push(@_) if @_; $obj }
sub fetch {
my $self = shift;
my $index = shift;
return $self-{array}[$index];
}
sub store {
my $self = shift;
my $index = shift;
my $data = shift;
my $old = undef;
if ($self-exists($index)) {
$old = $self-fetch($index);
$self-{counter}{$old}--;
}
$self-{array}[$index] = $data;
$self-{counter}{$data}++;
return $old;
}
sub exists {
my $self = shift;
my $index = shift;
return exists @{$self-{array}};
}
sub delete {
my $self = shift;
my $index = shift;
if ($self-exists($index)) {
$self-{counts}{$self-{array}[$index]}--;
delete $self-{array}[$index];
}
}
sub count {
my $self = shift;
my $data = shift;
return $self-{counter}{$data};
}
sub counts {
my $self = shift;
return %{$self-{counter}};
}
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
RE: idiom for filling a counting hash
-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 frightens me. I love it. Umm, yeah. On any given day, I half-agree with you. =Austin
Re: idiom for filling a counting hash
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
RE: idiom for filling a counting hash
-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 is almost readable. But unfortunately not correct. Junctions are value, not lvalues. That'll have to be fixed. I suppose if you tried to mix l- and r-values it'd cause a new class of error (assuming the junction collapsed that way) but why not bundle lvalues together? =Austin
Re: idiom for filling a counting hash
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 PROTECTED]; Er, did the hyper operator's direction flip? I thought it was: ++ [EMAIL PROTECTED]; Luke
Re: idiom for filling a counting hash
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. : : This situation is exactly what hyperoperators are for: : : ++» [EMAIL PROTECTED]; : : Er, did the hyper operator's direction flip? I thought it was: : : ++« [EMAIL PROTECTED]; There's a bug in the flight control softward that flips it 180° when you cross the equator. Larry
Re: idiom for filling a counting hash
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); # would mean %a += ( @a, keys %h)
I would like this sort of addition of hashes to allow
for two meanings. A counting hash can be used for testing
whether a key exists, but also for how many times it
has occurred.
So (in Perl 5):
add( %a, %b )
could work with:
++$a{$_} for keys %b
only if you are only interested in existance, but it should
work as:
while( my($k,$v) = each %b ) {
$a{$k} += $v;
}
so that you can merge one set of counts into another.
In Perl 6, this could be a function (perhaps wrapped in
an operator, I'm not especially concerned about that)
that runs through its list of keys and increments the
ones that are scalar, but for pairs it increments the key
by the value.
--
Re: idiom for filling a counting hash
Luke asked: Er, did the hyper operator's direction flip? I thought it was: ++ [EMAIL PROTECTED]; My bad. 'Tis indeed. Damian
Re: idiom for filling a counting hash
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 introducing new features that encourage new mistakes. Damian
Re: idiom for filling a counting hash
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 = sub { my %foo; $foo{$_}++ for @foo; }, i
J b = sub { my %foo; $_++ for @[EMAIL PROTECTED]; } }'
J Rate a b
J a 51121/s -- -9%
J b 56220/s 10% --
but those are setting the empty hash to values of 1's. you can do that
with a slice or map:
@[EMAIL PROTECTED] = (1) x @foo ;
my %foo = map { $_ = 1 } @foo ;
add those to the benchmark.
now if you wanted to increment the values of a hash already stuffed,
then values is cool:
$_++ for values %foo ;
but i do like the hyper version in p6.
i assume that this is ok since is not a logical shift anymore.
[EMAIL PROTECTED]++;
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
