[EMAIL PROTECTED] writes:
: On Sunday 20 January 2002 20:57, Larry Wall wrote:
: > I expect PRE and POST could inherit automatically according to the
: > usual rules of DbC, though how you implement that is something other
: > people have thought about more than me. I think that LAST doesn't
: > inherit. If you want to share common code, there's this neat Perl 6
: > invention called "subroutines" you can use.
:
: Funny you should say that. The question I hadn't asked yet:
:
: Since these blocks are all closures now, will the different methods for
: passing code blocks be interchangeable (or simplified)?
I don't think we can completely simplify it. The following two are
certainly interchangeable:
-> $a, $b { $a <=> $b }
{ $^a <=> $^b }
except that the first one can do things like:
-> $a is rw, $b { $a = $b }
while the second automatically does currying.
Certainly your good old-fashioned
sub ($a is rw, $b) { $a = $b }
can be used anywhere a CODE pointer is expected at runtime. I don't
know if I like
for @foo sub ($x) { ... }
but it could be made to work, provided we force C<sub> to start a term
as we've done with -> and left curly. I don't feel greatly motivated
to do that, however.
: User code code can pass '{ ... }' if a sub's prototype wants a coderef, to
: better match map and grep; sort can take a bare block or the name of a sub,
: but none of the three can take a reference to a sub. Whereas this mostly
: makes (made) sense, can code truly start being interchangable? Can I write
: reusable transformers and filters for map and grep, simply passing in a ref
: to the proper routine rather than the code block? How would this interact
: (or react) with curried code blocks?
I don't know how far we can push it. Certainly it would be really weird
to expect
BEGIN $code;
to work unless their were an earlier BEGIN that happened to set $code.
But if BEGIN has a prototype of (&), perhaps it's just parsed as a unary
operator and that just works. On the other hand, that's not how the
first argument of
grep $_, @foo
currently works in Perl 5. In that case, the first argument is being
forced to be treated as if it were curried:
grep $^a, @foo
But that means that $_ can't contain a sub reference! I suspect that
we have to outlaw forms of grep in which $_ auto-curries itself if we
want
grep $somesub, @foo
To be the same as
grep { $somesub() } @foo
I think it's fair to trade auto-currying of $_ for that flexibility.
: If this is a good first step, how far can it extend? Could I write a sub,
: and pass a reference to it directly to LAST, for instance:
:
: LAST $coderef;
:
: or would I simply wrap it?
:
: LAST {
: &$coderef;
: }
Well, a wrapper will always work, except that's not how you'd write it
in Perl 6. The & doesn't call the sub, the parens do. So you'd have
to say
LAST {
$coderef();
}
What I can't figure out is, when you write
LAST $coderef;
when would it actually do the %MY._LAST_list.push($coderef)?
Unfortunately, I think it has to do it at compile time, or we can't
guarantee that the LAST actually gets run if an exception is thrown
early. And in that case, $coderef is likely not set yet. This seems
like a recipe for confusion, if not disaster.
At the end of the day, I suspect [A-Z]+ blocks will really want to be
literal blocks because we want to do various sorts of analysis of
them at compile time. We wouldn't be able to tell at compile time if
POST $coderef;
does any horrible side effects, for instance, unless we guarantee that
$coderef is defined when the POST is compiled. I think we'd often
have people trying to write things like:
my $coderef = sub { ... };
LAST $coderef;
and then wondering why it says "Undefined LAST block" or some such.
Larry
