Smart Matching clarification
Looking through the table provided, I ran across the following: $_ $xType of Match ImpliedMatching Code == = == HashHash hash keys identical match if $_.keys.sort »eq« $x.keys.sort My understanding is that at the time this was written, the working theory was that Hash keys would always be strings. I'm wondering: should this entry replace 'eq' with '===' or 'eqv', so that non-string keys can also be compared for equivalent values? If so, which operator should replace 'eq'? (I'm leaning toward '===', since S03 defines '$a eq $b' as '~$a === ~$b'.) -- Jonathan "Dataweaver" Lang
Re: generic ordinal-relevant operators
> Yes. He also accepted the proposal to add min and max operators - > although I'm unsure why they weren't included as functions/methods > instead. It seems more natural to me to say 'max($a, $b, $c)' or > '($a, $b, $c).max' instead of '[max] $a, $b, $c' or '$a max $b max > $c'. Although it _does_ allow for such things as '$a max= $b' (which > is shorthand for something like '$a = $b if $a < $b'). And I suppose > that '&infix:' doesn't stop you from having '&max' as well. In true chicken and egg fashion: Which comes first the operator or the function. Do you define &infix: in terms of &max or vice versa. My guess is the operators should win because there could be some low-level shenanigans that optimize things. But maybe not. Paul
Re: List assignment question
On Wed, Nov 15, 2006 at 10:28:41AM -0600, Jonathan Rockway wrote: : For reference, this sort of operation works if you write it on two : lines, like: : : my ($a, $b); : ($a, undef, $b) = 1..3; : say "$a is 1 and $b is 3"; : : I'll look around in the source and see if I can make this work like : perl5 (unless that's a bad idea for some reason). That will just be "my ($a, $, $b) = 1..3" in Perl 6. It should be an error to try to modify undef, I think, and we have a notation for anonymous variables, so why not use it? Larry
Re: List assignment question
Vincent Foley wrote:
> Hello everyone,
>
> I was toying around with Pugs and I tried the following Perl 5 list
> assignment
>
> my ($a, undef, $b) = 1..3;
>
> Which gave me the following error message:
>
> Internal error while running expression:
> ***
> Unexpected ","
> expecting word character, "\\", ":", "*" or parameter name
> at line 1, column 14
For reference, this sort of operation works if you write it on two
lines, like:
my ($a, $b);
($a, undef, $b) = 1..3;
say "$a is 1 and $b is 3";
I'll look around in the source and see if I can make this work like
perl5 (unless that's a bad idea for some reason).
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: generic ordinal-relevant operators
Smylers wrote: Didn't Larry actually accept Darren's proposal and add the C and C operators? Yes. He also accepted the proposal to add min and max operators - although I'm unsure why they weren't included as functions/methods instead. It seems more natural to me to say 'max($a, $b, $c)' or '($a, $b, $c).max' instead of '[max] $a, $b, $c' or '$a max $b max $c'. Although it _does_ allow for such things as '$a max= $b' (which is shorthand for something like '$a = $b if $a < $b'). And I suppose that '&infix:' doesn't stop you from having '&max' as well. -- Jonathan "Dataweaver" Lang
Re: List assignment question
Mark J. Reed wrote:
> I distinctly recall having to do things like (my $a, undef, my $b) to
> avoid errors because you can't assign to undef. Maybe I'm just
> hallucinating.
Maybe :)
$ perl -Mstrict -e 'my ($a, undef, $b) = 1..3; print "$a $b\n";'
1 3
This works as far back as v5.6.0 (which is the oldest I have around).
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: List assignment question
> (my $x, undef, my $y) = 1 .. 3; parses to my ($x, undef, $y) = 1 .. 3 > and always has as far as I know, so please share your hallucinogens > with the list:) > Sadly, the hallucinogens are essential, not external. But I'm pretty sure those are two different parse trees. They have the same B::Terse and B::Deparse output on 5.8.
Re: generic ordinal-relevant operators
TSa writes: > ... one question remains that might actually make Duncan's proposal > pointless. Didn't Larry actually accept Darren's proposal and add the C and C operators? > Are the comparison operators available for overloading just like any > other operator Yes. This feature is used often enough in Perl 5 classes, and I'm almost certain there are no plans to remove it from Perl 6. Smylers
Re: generic ordinal-relevant operators
HaloO Larry, you wrote: You guys should read The Search for the Perfect Language, by Umberto Eco. It would disabuse you of the notion that perfect orthogonality is possible or even desirable. I'm sorry if my contributions to this thread are annoying. But one question remains that might actually make Duncan's proposal pointless. Are the comparison operators available for overloading just like any other operator or is the casting of the operands performed *before* dispatch sees the actual types? If overloading is possible than the numeric and string comparison should be adhered to "in spirit". I can imagine to have a role Order that composes the comparison ops. E.g. Order[Num] composes <, >, >=, <= and <=>. Order[Str] composes lt, gt, ge, le and leg. You get both when composing Order[Num|Str]. The generic Order[Foo] would compose before, after, their negations and cmp. Order would imply Comparable, that is the equality checks ===, eqv, == and eq. Comparable would take the same type parameters as Order and compose different sets of ops accordingly. The binding check =:= is hardly useful for overloading because it operates on the namespace level. Regards, TSa. --
