Damian writes "Exegesis 4 is now on-line. There are some fundamental changes to Perl 6 since Apocalypse 4, so you might want to re-read that too -- to see what was Rule-2'd in the interim."
our %operator is private //= (
'*' => { $^a * $^b },
'/' => { $^a / $^b },
'~' => { ($^a + $^b) / 2 },
);
push @stack, %operator{$token}(@args)
Re:$^a and $^b # how assigned in example?
Damian on 2002-04-03T07:53:30
I don't see how $^a and $^b get assigned in pairs from @args ? I thought that the $^ magic variables had to be named.
A closure with "$^ magic variables" such as:
{ $^a * $^b }
is equivalent to an anonymous subroutine like this:
sub ($^a, $^b) { $^a * $^b }
That sub takes two parameters, so when it's called with an array, the array is flattened to two values, which are then assigned to $^a and $^b in order. Just as with any other subroutine.
Magic $^ variables are only magic in that they allow a subroutine to be declared without an explicitsubkeyword or an explicit parameter list. Instead, their parameter list is constructed implicitly: it's just the alphabetically sorted list of the names of all the magic $^ variables within the block.
And, because they're really just a normal subroutine (that is declared abnormally), such closures are certainly allowed to take named parameters. But they're not required to do so.Re:$^a and $^b # how assigned in example?
Matts on 2002-04-03T10:29:42
Wow, that's going to make writing obfuscated code so much easier!It's swings and roundabouts I guess...
pdcawley on 2002-04-03T18:45:59
Yes, you can use all the new expressiveness of Perl 6 in painfully obfuscatory ways, but it's also possible to use them to improve readability. For instance, on the perl6 language list we discussed how you'd declare an abstract method in Perl 6.
There's no formal way to do that in Perl5. You could use one of the various Class building helper modules on CPAN (Class::MethodMaker et al), or you could just doBut how can a reader tell the difference between your abstract method andsub an_abstract_method;say? Sure you could add a comment, but (speaking personally) any comment that isn't a 'class comment' at the top of the class declaration stating what the class is for generally starts me worrying that either the comment is unnecessary, or the code it's commenting on is too complex.sub a_forward_declaration;
In Perl 6, the problem goes away:Simple, expressive, self documenting. And, the documentation stays in place through the vicissitudes of perl -MO=Deparse SomeFile.pm or whatever it's going to be called in Perl 6. Which is important when you're trying to write a refactoring browser.method display_on ($a_medium) is abstract {...}Re:$^a and $^b # how assigned in example?
pdcawley on 2002-04-03T07:58:16
Well, @args is already a two item list, but I think that, as written, you'll see $^a becoming @args and $^b becoming undef.
The fix is simple though; just change the invocation to push @stack, %operator{$token}(*@args), unary '*' being the list flattening operator introduced in Apocalypse 3.Re:$^a and $^b # how assigned in example?
Damian on 2002-04-03T08:48:12
Hmmmmm. Interesting point. I've asked Larry to clarify the semantics in such situations, and will post an update here when I get an answer.Re:$^a and $^b # how assigned in example?
pdcawley on 2002-04-03T13:25:43
Even if *@args isn't required, I argue that it should be considered good style; you're making your assumptions explicit.Re:$^a and $^b # how assigned in example?
Damian on 2002-04-03T21:33:27
Larry confirmed that it is required.
I'll be fixing it on-line ASAP.
Thanks for pointing out this bug in my wetware Perl 6 compiler!;-)
Re:Are these equal?
TimToady on 2002-04-04T01:44:05
Yes.
LarryRe:Are these equal?
hossman on 2002-04-06T20:34:33
Are you saying that the =~ is going to be defined such that($paco =~ $yakko) == ($paco =~ $yakko)will allways be true? (or are you saying that just the 4 examples $Bob listed will allways be true)What if $paco and $yakko are both sub refs? there's no garuntee that $yakko.($paco) will ever be equal to $paco.($yakko).
for that matter, what about the list behavior Damian describes...
What happens in this scenerio...if $value =~ ('a',/\s/,7) {...}
# true if $value is eq to 'a'
# or if $value contains whitespace
# or if $value is == to 7
That final example illustrates some of the extra intelligence that Perl 6's =~ has: When one of its arguments is a list (not an array), the "smart match" operator recursively "smart matches" each element and ORs the results together, short-circuiting if possible.
if ($sub1 =~ ($sub2, $sub3)) {... } is it equivilent to
($sub1.($sub2) || $sub1.($sub3))? Or($sub2.($sub1) || $sub3.($sub1))?Re:Are these equal?
Damian on 2002-04-06T23:05:41
He's saying the latter. The matching rules are supposed to be "sensible" and "reasonable" (for sufficiently vague values of those two wordsAre you saying that the =~ is going to be defined such that ($paco =~ $yakko) == ($paco =~ $yakko) will allways be true? (or are you saying that just the 4 examples $Bob listed will allways be true);-) The table in A4 lists the behaviours of =~ under various combinations of arguments.
That table doesn't mention the sub-ref/sub-ref case, but it would seem sensible and reasonable (to me, at least) that =~ would just try referential equality there. Of course, Larry's mileage may vary on that point.What if $paco and $yakko are both sub refs? there's no garuntee that $yakko.($paco) will ever be equal to $paco.($yakko).According to the table, it's reversible too.for that matter, what about the list behavior Damian describes...Neither, I think. IMHO it should be distributed referential equality: $sub1 == $sub2 || $sub1 == $sub3What happens in this scenerio...if ($sub1 =~ ($sub2, $sub3)) {is it equivilent to ($sub1.($sub2) || $sub1.($sub3)) ? Or ($sub2.($sub1) || $sub3.($sub1)) ?... }
Re:when %var
Damian on 2002-04-08T04:14:07
It also seems easier for hash/scalar matching to mean "scalar exists as a hash key", and write "when %var{$_}" when you want truth, than to have it mean "value associated with scalar is true", and write "when exists %var{$_}" when you want existence.Personally, I would agree, especially from a "hash-keys-form-a-set" perspective. But we also have the case of sometimes wanting:
which might also be useful in the example.when defined %var{$_} {...}So we have three viable alternatives and only one of them can be the DWIMish one.
When designing the original Switch.pm module (the prototype for given/whens) I chose the "is true" variant, rather than the "is defined" or "is existent" alternatives.
The main reason was because that it's still relatively easy to get the other behaviours:
# Switch according to definedness...
given { defined %data{^$key} } {
when 'key1' {...}
when 'key2' {...}
...
}
# Switch according to existence...
given { exists %data{$^key} } {
when 'key1' {...}
when 'key2' {...}
...
}
# Switch according to either...
sub def($key) { { defined %^hash{$key} } }
sub ex($key) { { exists %^hash{$key} } }
given %data {
when def 'key1' {...}
when ex 'key1' {...}
when def 'key2' {...}
when ex 'key2' {...}
...
}(By the way, Oh ye Gods of Use Perl, the lameness filter rejected the above post until I added enough pointless extra text here to satisfy it. That suggests to me that the lameness filter needs a couple of passes through itself.
;-)