Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 3:37 PM +0000 1/18/02, Piers Cawley wrote:
>>Michael G Schwern <[EMAIL PROTECTED]> writes:
>>
>>Hmm... making up some syntax on the fly. I sort of like the idea of
>>being able to do
>>
>> class File;
>> sub foreach ($file, &block) is Control {
>> # 'is Control' declares this as a control sub, which, amongst
>> # other things 'hides' itself from caller. (We can currently
>> # do something like this already using Hooks::LexWrap type
>> # tricks.
>>
>> open my $fh, $file or die $!; POST { close $fh }
>> while (<FILE>) {
>> my @ret = wantarray ?? list &block() :: (scalar &block());
>> given $! {
>> when c::RETURN { return wantarray ?? @ret :: @ret[0] }
>> }
>> }
>> }
>>
>>This is, of course, dependent on $! not being set to a RETURN control
>>'exception' in the case where we just fall off the end of the block.
>
> I don't think you'll see $! being set to anything other than real
> errors. Larry may change that, but I'd doubt it. It's more a global
> status than anything else. Exceptions would go elsewhere, I'd hope.
Um... I'm not sure that's how I read the Apocalypse. And if it doesn't
get set how on earth are we going to be able to tell how a block
exited in the case of home rolled looping/iterating constructs where
we're going to want to write:
sub foo {
...
File.foreach($file_path) {
...
return ($someval) if /some_pattern/;
...
}
}
and have foo return.
Maybe we'll have to have something like:
while (<FILE>) {
try {
temp c::RETURN is Error;
temp c::NEXT is Error;
temp c::REDO is Error;
temp c::LAST is Error;
wantarray ?? list &block() :: (scalar &block());
DEFAULT { throw };
}
}
Then, because the control structures are temporarily Errors within the
scope of the try block they get thrown up to the first thing that can
handle them. In the case of NEXT/REDO/LAST, that's the while loop, and
in the case of the RETURN, that's the enclosing subroutine. But it
seems kludgy as hell.
> I personally would like to see subs be taggable as transparent to
> yielding, so if you call a sub, and it calls a sub, that inner sub
> could yied out of the caller if the caller was transparent. Not, mind,
> that the scheme doesn't have issues, but...
>[...]
>>It's also dependent on being able to get continuations from caller
>>(which would be *so* cool)
>
> For some brainwarping version of cool. :)
Hmm... the example I wrote which might possibly have used
continuations got wiped 'cos I realised I wasn't exactly clear on how
they were going to work. But I still think being able to grab a
continuation from up the stack somewhere could be handy, allowing
syntax like:
&block.call_from($continuation);
Which is sort of nice, and sort of really, really evil. The thing is,
given continuations and $continuation.want (so I can work out what
context the continuation called in...) I can see how to implement it:
class BLOCK;
sub call_from ($continuation) {
given $continuation.want {
when LIST { $continuation.return(list .yield) }
default { $continuation.return(scalar .yield) }
}
}
Of course, I could have got *completely* the wrong end of the stick
about continuations. And this example doesn't do the 'right thing' for
caller, but hey, it's a start.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
