[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