Re: assign to magic name-of-function variable instead of return
On Tue, Feb 06, 2001 at 05:01:03AM +1100, Damian Conway wrote: Really? Are lexicals in the sub visible in the post handler? No. Only the original arguments and the return value. (Of course I realize *F does not illustrate this...) Exactly. ;-) Actually, I do agree that Perl 6 ought to provide a universal "destructor" mechanism on *any* block. For historical reasons, I suppose it should be Ccontinue, though I would much prefer a more generic name, such as Ccleanup. Cmop ? :-) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: assign to magic name-of-function variable instead of return
On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote:
RFC 271 handles this. Your example would be:
sub readit {
open F, " $f" ...
scalar(F)
}
post readit {
close F;
}
The connection between these two things is not strikingly obvious. I'd
like it better, if you put the post thing inside the sub readit's
contents. It can even be anonymous.
sub readit {
open F, " $f" ...
scalar(F)
POST {
close F;
}
}
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, " $f" ...
scalar(F)
}
--
Bart.
Re: assign to magic name-of-function variable instead of return
Bart Lateur [EMAIL PROTECTED] writes:
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, " $f" ...
scalar(F)
}
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, " $f" or die;
scalar(F)
}
But I think this is getting ridiculous. $slightly_joking++; I'd
propose a much nicer and cleaner concept:
sub readit {
open F ... ;
prog1 {
scalar(F);
close F;
}
}
'prog1' executes all expressions in the block, and returns the result
of the first expression. Of course, we also need prog2, prog3, and so
on ... $slightly_joking--;
All that POST and such do, is obfuscate the flow of control. I doubt
that outweighs the small benefits.
-- Johan
Re: assign to magic name-of-function variable instead of return
Johan Vromans wrote:
Would the POST be executed if the open fails? Why? Why not?
Of course. It's a post-handler on the sub.
All that POST and such do, is obfuscate the flow of control.
No more so than contine{} on a loop, or END{} in a file, or DESTROY{}
in a class.
--
John Porter
You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of return
Tony Olekshy wrote:
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause (inside or outside).
Why? For that matter, why must "try" itself be explicit?
It says, "I'm probly gonna put some exception catchers on this block,
so if I do, choke fatally if I haven't put the magic word up here."
This strikes me as exceedingly un-Perlish, though of course quite
natural in BD languages like C++ and Java.
Once you have an always clause, it has to be invoked during stack
unwinding caused by the raising of an exception.
Yes, that's Perl: it does the hard stuff for you.
This means there
is an implied goto-on-exception pending throughout the scope
affected by the always clause. This is not like if/else, for, or
while, which are all marked up front, and only have explicit variant
flow control. It is like eval, but note that eval is marked up
front too.
Note that END{} and BEGIN{} require no formal introduction.
You can put them anywhere you want, and they run at the proper time.
Even continue{} is an implicit goto. And it requires no introduction
either.
Like eval, the beginning of the scope for non-local flow control
(such as always and catch) should be explicitly delimited, typically
by using a keyword like try.
Back into the ivory tower, wench! :-)
A left-curly is all the introduction I need.
Say you run into one of the
cross-product constructs in some code. Is it clear to you what
the scope and semantics are? Is it clear when always applies
to the foreach block, and when it applies to the catch block,
and when it applies to the foreach statement?
Obviously we can't mix the two syntaces. Only having catchy blocks
inside prevents the ambiguity you're talking about.
Assuming no dangling blocks, what about the following is ambiguous?
foreach ... { ... catch { ... } always { ... } }
What about the try/finally cases? It's pretty clear, IMHO,
that the catch and finally clauses apply to the try statement,
There is no try, there is only do. :-)
previous blocks are critical, because under various circumstances
blocks need to be triggered by exceptions raised in previous
blocks.
If the blocks were lexically nested, we would avoid entirely this
"previous block" mess.
--
John Porter
You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of return
Johan Vromans [EMAIL PROTECTED] writes:
[...]
But I think this is getting ridiculous. $slightly_joking++; I'd
propose a much nicer and cleaner concept:
sub readit {
open F ... ;
prog1 {
scalar(F);
close F;
}
}
'prog1' executes all expressions in the block, and returns the result
of the first expression. Of course, we also need prog2, prog3, and so
on ... $slightly_joking--;
If you're going to reimplement Lisp poorly, at least reimplement the
right bits of Lisp poorly. In this case, you want unwind-protect, not
prog1. You can see the difference e.g. when throwing.
Here's the Emacs Lisp documentation of unwind-protect:
`unwind-protect' is a built-in function
Documentation:
Do BODYFORM, protecting with UNWINDFORMS.
Usage looks like (unwind-protect BODYFORM UNWINDFORMS...).
If BODYFORM completes normally, its value is returned
after executing the UNWINDFORMS.
If BODYFORM exits nonlocally, the UNWINDFORMS are executed anyway.
You can read the relevant bit of CLtL2 at
http://www.supelec.fr/docs/cltl/clm/node96.html .
All that POST and such do, is obfuscate the flow of control. I doubt
that outweighs the small benefits.
However, unwind-protect is useful. It's either use that or use
something destructor-related. That just sits on top of some
unwind-protect-like hack in the internals.
--
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658117 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: assign to magic name-of-function variable instead of return
At 09:59 AM 2/7/01 -0500, John Porter wrote:
Tony Olekshy wrote:
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause (inside or outside).
Why? For that matter, why must "try" itself be explicit?
It says, "I'm probly gonna put some exception catchers on this block,
so if I do, choke fatally if I haven't put the magic word up here."
This strikes me as exceedingly un-Perlish, though of course quite
natural in BD languages like C++ and Java.
I want the 'try' there for my sake, not Perl's; I don't care whether some
other languages couldn't parse the block without the word, but for me, it
helps alert me that the following block is subject to non-local control
flow rules.
I'd rather have the 'try' there for the same reason I want to see the 'do'
in "do { ... } while ..." (well, leaving aside the fact that it would be
unparseable without it). But I certainly understand your preference.
--
Peter Scott
Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of return
At 02:17 PM 2/7/01 -0500, John Porter wrote:
Peter Scott wrote:
I want the 'try' there for my sake, not Perl's; ... it
helps alert me that the following block is subject to non-local control
flow rules.
Huh? Down that road lies the Java madness.
eval {
foo();
};
sub foo {
bar();
}
sub bar {
die $barney;
}
All three of these blocks are "subject to non-local control flow rules",
including the body of foo.
Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
the following block is going to be subject to exception handlers which will
immediately follow as siblings of the block. Somewhat as I would look at
an if...elsif...else construct, it helps me put the block in context as I'm
reading it and also look ahead fo those handlers. I prefer this to
discovering a handler as I'm reading and then looking for the enclosing
block, or coming across an undecorated block and scanning to see if this is
because it has embedded handlers or is to create a closure, or to use a
redo, or...
--
Peter Scott
Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of return
Peter Scott wrote: Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that the following block is going to be subject to exception handlers which will immediately follow as siblings of the block. O.k. That makes sense if some blocks can be try blocks (by adding the approprate decoration) and some aren't. But I don't see the advantage of it if any and every block is implicitly a try block. -- John Porter
Re: assign to magic name-of-function variable instead of return
At 05:07 PM 2/7/01 -0500, John Porter wrote: Peter Scott wrote: Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that the following block is going to be subject to exception handlers which will immediately follow as siblings of the block. O.k. That makes sense if some blocks can be try blocks (by adding the approprate decoration) and some aren't. But I don't see the advantage of it if any and every block is implicitly a try block. Me neither. I don't want that. -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
sub DirectBubbleSort(){
my ($i,$t) = (-1,0);
while (++$i = $#$__){
$$__[$i] $$__[1+$i] and $t++ and @$__[$i,1+$i] = @$__[1+$i,$i];
};
$t and @$__ = DirectBubbleSort;
}
@SomeList = DirectBubbleSort; # instead of DirectBubbleSort(\@SomeList)
If I saw a module like this, I wouldn't use it ever! I think I would even
`undef' all my variables explicitly before using them as lvalues, just in
case... Serious, man, that is a sick mind!
And I don't see what the problem with DirectBubbleSort(\@SomeList) is. It's
rather explicit, and is very clear about what is done. Using a (\@)
prototype on DirectBubbleSort would be ok too, since its name says right
what it does and everybody likes some vanilla syntax. But making it
@SomeList = DirectBubbleSort is the most error-prone thing I see! Nobody
will get it right on first use...
- Branden
Re: assign to magic name-of-function variable instead of return
James Mastros wrote: On Mon, Feb 05, 2001 at 08:43:02PM +0100, [EMAIL PROTECTED] wrote: On Mon, Feb 05, 2001 at 11:46:48AM -0500, James Mastros wrote: By the time you get to the last line, you've already forgoten WTF you named the return variable. Eh, I don't think that bad memory, or a bad variable naming scheme justifies this new feature. A new feature doesn't need that much justification. And nobody is advocating getting rid of "return". Yes it does. Otherwise, we get even more bloated than now! - Branden
Re: assign to magic name-of-function variable instead of return
[EMAIL PROTECTED] wrote: Hmmm. If there's such an "always" block, I'd like to see it on all blocks, including the continue [1]. But then, it becomes hard to figure out to which block the always belongs That's precisely why these things should be shoved inside rather than dangling off the end. JMHO. -- John Porter
Re: assign to magic name-of-function variable instead of return
John Porter wrote:
[EMAIL PROTECTED] wrote:
Hmmm. If there's such an "always" block, I'd like to see it on
all blocks, including the continue [1]. But then, it becomes
hard to figure out to which block the always belongs
That's precisely why these things should be shoved inside rather
than dangling off the end. JMHO.
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause (inside or outside).
Once you have an always clause, it has to be invoked during stack
unwinding caused by the raising of an exception. This means there
is an implied goto-on-exception pending throughout the scope
affected by the always clause. This is not like if/else, for, or
while, which are all marked up front, and only have explicit variant
flow control. It is like eval, but note that eval is marked up
front too.
Like eval, the beginning of the scope for non-local flow control
(such as always and catch) should be explicitly delimited, typically
by using a keyword like try. Consider the following two cases:
foreach ... { try { ... } catch { ... } finally { ... } }
try { foreach ... { ... } } catch { ... } finally { ... }
now take out the statement keyword and use magic dangling clauses:
foreach ... { { ... } catch { ... } finally { ... } }
{ foreach ... { ... } } catch { ... } finally { ... }
The signal to noise ratio has gone down, no?
In fact, the cross product of these cases and the alternatives for
dangling always block placement produce these four cases:
foreach ... { ... catch { ... } always { ... } }
{ foreach ... { ... } catch { ... } always { ... } }
foreach ... { ... } catch { ... } always { ... }
{ foreach ... { ... } } catch { ... } always { ... }
Now play the problem backwards. Say you run into one of the
cross-product constructs in some code. Is it clear to you what
the scope and semantics are? Is it clear when always applies
to the foreach block, and when it applies to the catch block,
and when it applies to the foreach statement?
What about the try/finally cases? It's pretty clear, IMHO,
that the catch and finally clauses apply to the try statement,
simply because try is a statement of which they are part. At that
point, the body of the try block and any previous catch or finally
blocks that are part of the same try statement are apparent. The
previous blocks are critical, because under various circumstances
blocks need to be triggered by exceptions raised in previous
blocks.
From a psychology of programming languages perspective, wrapping the
whole mechanism up into a statement per se provides the foundation
upon which we can attempt to avoid the conceptual disaster produced
by dangling clauses. Mixing up traditional sequential flow-control
constructs and non-local stack-unwinding flow-control constructs,
without clearly delimiting what you're doing, is (I think) a less
than optimal idea.
Remember that one of the main uses for catch and always clauses is
error handling (as in, close file if opened even if error during
processing thereof). I don't like language constructs that obfuscate
my attempts to get error handling right (such as they are) because
errors in error handling tend to make my code behave relatively poorly.
Yours, c, Tony Olekshy
PS: since we're completely off subject, can we continue this under
http:[EMAIL PROTECTED]/msg05604.html
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
I don't really see what this buys us. First, `return' already handles it,
and it finishes sub execution. How would it be handled with that? `foo = 42;
last;'? I think `return 42;' is better... And `return' handles scalar/list
context, mainly because it isn't a special variable, it is a statement. IMO,
`return' is perfect for the job, since it combines the familiarity of
passing a list as parameter to a statement, what is done in all practically
all Perl statements, and has no problem with context to return a scalar or a
list from a sub.
I really think that changing a familiar thing as `return', which is familiar
even to programmers of other languages, to a cryptic thing as $__/@__, just
to save the one value copy, isn't any good at all.
If optimization is _so_ needed, I think the parser/compiler should identify
those situations and optimize them in subs that use the same variable always
in `return' and bind it to the result value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
I don't really see what this buys us. First, `return' already handles it,
and it finishes sub execution. How would it be handled with that? `foo = 42;
last;'? I think `return 42;' is better... And `return' handles scalar/list
context, mainly because it isn't a special variable, it is a statement. IMO,
`return' is perfect for the job, since it combines the familiarity of
passing a list as parameter to a statement, what is done in all practically
all Perl statements, and has no problem with context to return a scalar or a
list from a sub.
I really think that changing a familiar thing as `return', which is familiar
even to programmers of other languages, to a cryptic thing as $__/@__, just
to save the one value copy, isn't any good at all.
If optimization is _so_ needed, I think the parser/compiler should identify
those situations and optimize them in subs that use the same variable always
in `return' and bind it to the result value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
Re: assign to magic name-of-function variable instead of return
James Mastros wrote: Oh, here's an idea WRT extending the concept to cover both scalar and list assignment: Have $^R be the return in scalar context, and @^R be the return in list context. If @^R is unset, then a one-element list of $^R is returned. I don't like where this is leading. Currently perl does not allow modification of lists (vs. arrays). The operations supported for lists are a tiny subset of those supported for arrays: assignment-from, single-item index, and last-element-of. Simply setting up an array alias to a list won't magically give us all those array operations for the list. In order to C push @^R , there has to be a data structure there that supports the push operator. And if that is going to be the case, then I don't see the point in all this over having your own array variable and returning that when you're done. -- John Porter You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of return
Simon Cozens wrote: Assigning to barewords? Blurgh. At the very least, make @subname and $subname special lexicals. Or eliminate $ and @ from the language. :-) or rather :-/. -- John Porter Ann wenno haddum billizac...
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 08:56:05AM -0200, Branden wrote:
I don't really see what this buys us. First, `return' already handles it,
and it finishes sub execution. How would it be handled with that? `foo = 42;
last;'? I think `return 42;' is better...
That's the thing. return and setting the fname var have different primary
applications. For a function where you compute a value and return it,
"return" is wonderful. OTOH, for functions that look more like {startup;
compute; teardown}, magic-varable is nice. Think of the functions where you
have a varable named $ret or somesuch, and you compute it, have another few
lines or few screens of code, and then say "return $ret". I don't write
many of those, but sometimes they're nice.
And `return' handles scalar/list
context, mainly because it isn't a special variable, it is a statement. IMO,
`return' is perfect for the job, since it combines the familiarity of
passing a list as parameter to a statement, what is done in all practically
all Perl statements, and has no problem with context to return a scalar or a
list from a sub.
Yep. That's the rub. It doesn't "feel" like a statement, it "feels" like
an assignment. But we still want it to have many of the nice properties of
a statement, like having list and scalar contexts. A good solution to this
I have not; the best I can offer is two magic values, $^R and @^R. And, as
sombodyoranother pointed out, @^R can't be a real array, only a list. (I
don't think that will be a problem, though.)
[stuff about manual vs. automatic return-stack elminition]
Yeah, you're probably right. But return-as-assignment has certian nice
features from a stylistic viewpoint as well as an optimizational one.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 10:35:56AM -0500, John Porter wrote: Or eliminate $ and @ from the language. :-) or rather :-/. Well, you can do that now that foo = bar; calls the AUTOLOADed lvalue sub foo. The rest of the implementation is left as an exercise for the reader. :) -- On our campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University. - John Lions (U. of NSW)
Re: assign to magic name-of-function variable instead of return
Simon Cozens wrote: On Mon, Feb 05, 2001 at 10:35:56AM -0500, John Porter wrote: Or eliminate $ and @ from the language. :-) or rather :-/. Well, you can do that now that foo = bar; calls the AUTOLOADed lvalue sub foo. The rest of the implementation is left as an exercise for the reader. :) Well, try that on strict 'subs'... - Branden
Re: assign to magic name-of-function variable instead of return
Damian Conway wrote:
RFC 271 handles this. Your example would be:
sub readit {
open F, " $f" ...
scalar(F)
}
post readit {
close F;
}
Really? Are lexicals in the sub visible in the post handler?
(Of course I realize *F does not illustrate this...)
--
John Porter
Ann wenno haddum billizac...
Re: assign to magic name-of-function variable instead of return
Damian Conway wrote:
Actually, I do agree that Perl 6 ought to provide a universal "destructor"
mechanism on *any* block. For historical reasons, I suppose it should be
Ccontinue, though I would much prefer a more generic name, such as
Ccleanup.
But in some sense it's much more like the file-level END block.
It should have visibility to the lexicals in the block to which
it applies. That's why, as I advocated wrt catch blocks in,
for example,
http:[EMAIL PROTECTED]/msg02294.html
that the "handler" block should be nested within the block to
which it pertains, in much the same way that BEGIN and END blocks
reside inside the file to which they pertain.
So:
sub readit {
open F, " $f" or die "$f: $!";
F;
catch { ... }
end { close F }
}
--
John Porter
You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 11:46:48AM -0500, James Mastros wrote:
In most languages, you do this with
{
$ret = 42;
close FILE;
unlock $stuff;
#yadda
return $ret;
}
By the time you get to the last line, you've already forgoten WTF you named
the return variable.
Eh, I don't think that bad memory, or a bad variable naming scheme
justifies this new feature.
If you forget how you name your variables you have much bigger problems
than to have to type 'return'.
Abigail
Re: assign to magic name-of-function variable instead of return
[EMAIL PROTECTED] wrote:
use End;
{ my $foo = end {print "Leaving the block\n"};
...
last; # Prints "Leaving the block\n".
...
}
Yep, that's *perfect*, for a proof of concept.
--
John Porter
Re: assign to magic name-of-function variable instead of return
James Mastros wrote: I'm quickly getting more confused here then I want to be, so I'm going to stop now. -=- James Mastros James: Thanks. One confusing thing is that I apparently switched from thinking $__ shuld be an alias to thinking $__ should be a reference; which makes (wnatarray?@$__:$$__) the alias for the lvalue. -- David Nicol 816.235.1187 [EMAIL PROTECTED] www.tmcm.com, dammit
Re: assign to magic name-of-function variable instead of return
[EMAIL PROTECTED] wrote:
Does that mean there's going to be a @__ as well, for uses in list context?
If so, what happens with:
sub some_sub {
@__ = qw /foo bar baz/;
}
my $fnord = some_sub;
If there isn't going to be a @__ of some sorts, how is the case of the sub
being called in list context going to be handled?
Abigail
If $__ is a reference to our lvalue, if any, instead of an alias, since
references are all scalar, we can take Cref($__) to get a finely
grained Cwant function.
And when the sub is called in list context, @$__ will be the list.
This allows intrusive functionality to fiddle with lvalue parts:
sub DirectBubbleSort(){
my ($i,$t) = (-1,0);
while (++$i = $#$__){
$$__[$i] $$__[1+$i] and $t++ and @$__[$i,1+$i] =
@$__[1+$i,$i];
};
$t and @$__ = DirectBubbleSort;
}
@SomeList = DirectBubbleSort; # instead of DirectBubbleSort(\@SomeList)
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
Re: assign to magic name-of-function variable instead of return
Damian Conway wrote: Actually, I do agree that Perl 6 ought to provide a universal "destructor" mechanism on *any* block. For historical reasons, I suppose it should be Ccontinue, though I would much prefer a more generic name, such as Ccleanup. Both of the exception handling RFCs discuss an "always" block that is equivalent to a universal destructor mechanism on any block. Cleanup is a nice word, but maybe sometimes you want to do something that doesn't really fit the connotation of cleaning up. Whereas "always" just says when it is done. return ( $stuff, $morestuff, $whatever ) always close F; -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers - Stuff below this added by NetZero - Shop online without a credit card http://www.rocketcash.com RocketCash, a NetZero subsidiary
Re: assign to magic name-of-function variable instead of return
return ( $stuff, $morestuff, $whatever ) always close F;
I *really* like that keyword.
Though I'd prefer to see it as a block suffix:
sub {
...
return $yadda_yadda;
}
always { close F }
Then you could add it to loops as well, in conjunction with the Ccontinue:
while (1) {
... # add to $text in complex ways
}
continue { $text .= "\n"; } # separate with newlines
always { $trycount++ }# count attempts (including last)
Damian
Re: assign to magic name-of-function variable instead of return
Glenn Linderman wrote:
Cleanup is a nice word, but maybe sometimes you want to do something that
doesn't really fit the connotation of cleaning up. Whereas "always" just says
when it is done.
return ( $stuff, $morestuff, $whatever ) always close F;
That doesn't look like a block to me.
What it *does* look like is the statement modifier form of if/unless,
the difference being that it always permits the statement to
execute, regardless of the value of the predicate.
But under that interpretation, it doesn't happen at sub exit,
even when appended to return():
return F always close F; # statement modifier?
would do the wrong thing.
I wonder if it shouldn't rather be
return F;
always { close F } # a catchy block.
--
John Porter
You can't keep Perl6 Perl5.
Re: assign to magic name-of-function variable instead of return
John Porter wrote:
http:[EMAIL PROTECTED]/msg02294.html
that the "handler" block should be nested within the block to
which it pertains, in much the same way that BEGIN and END blocks
reside inside the file to which they pertain.
So:
sub readit {
open F, " $f" or die "$f: $!";
F;
catch { ... }
end { close F }
}
FWIW I agree that this is better than doing the parts in different
places,
post readit {...}
seems like it could be very far away from
sub readit {...
and cause some serious AAAD confusion.
Damian?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
Re: assign to magic name-of-function variable instead of return
On Mon, Feb 05, 2001 at 11:39:47AM +0100, Bart Lateur wrote:
I wish this could be
extended to doing recursive calls without having to say the subs own
name, again.
Here's an idea. I think this has probably been discused before, but perhaps
not.
1) caller's return should be callable as a sub (IE have it's {} operator
overloaded), to call your caller.
2) caller(-1), should return your own information. (If it doesn't already
return somthing. Which I don't think it does.
3) Passing caller() a version-vector should be able to retrive information
on scopes that caller doesn't (IE any scope not a do, require, eval, or
sub-call.)
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
Damian Conway wrote:
return ( $stuff, $morestuff, $whatever ) always close F;
I *really* like that keyword.
Though I'd prefer to see it as a block suffix:
sub {
...
return $yadda_yadda;
}
always { close F }
In RFC 119, I allowed the "always" syntax to be applied to statements. Of
course, blocks are statements on steriods, so one can allow a block on either
side of the always keyword, achieving both effects.
Then you could add it to loops as well, in conjunction with the Ccontinue:
while (1) {
... # add to $text in complex ways
}
continue { $text .= "\n"; } # separate with newlines
always { $trycount++ }# count attempts (including last)
RFC 119 didn't say much about applying it to looping blocks, mostly because I
didn't think of the possible implications. When doing so, the big decision
would be whether the always RHS statement is executed once per loop, or just
once. Since you can always
{ while (1) {
... # add to $text in complex ways
}
continue { $text .= "\n"; }# separate with newlines
}
always { $trycount++ } # count attempts (including last)
I think I'd prefer that it be executed once per loop.
And to perhaps satisfy Abigail, one can apply always to a continue block
slightly indirectly:
while (1) {
... # add to $text in complex ways
}
continue {
{ $text .= "\n"; } # separate with newlines
always { $trycount++ } # count attempts
}
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
- Stuff below this added by NetZero -
Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary
Re: assign to magic name-of-function variable instead of return
James Mastros [EMAIL PROTECTED] writes:
On Thu, Feb 01, 2001 at 07:36:59PM -0600, David L. Nicol wrote:
And I always hated that about VB and Pascal -- you can assign to the magic
variable, but can't modify it.
That was before the invention of auto-assignment operators. In the
70s, Burroughs Extended Algol did it this way. So it would be
perfectly okay to write
sub foo {
foo = ...;
...;
foo += 5;
}
-- Johan
Re: assign to magic name-of-function variable instead of return
On Sun, Feb 04, 2001 at 05:30:59PM +0100, Johan Vromans wrote:
James Mastros [EMAIL PROTECTED] writes:
And I always hated that about VB and Pascal -- you can assign to the magic
variable, but can't modify it.
That was before the invention of auto-assignment operators. In the
70s, Burroughs Extended Algol did it this way. So it would be
perfectly okay to write
sub foo {
foo = ...;
...;
foo += 5;
}
Right, but you can't do
sub foo {
foo = ...;
...;
if (foo == 42) {
foo=12;
}
}
Mind you, I'm not saying that it's a Bad Thing to offer it, I'm just saying
that /I/ wouldn't use it. TWMWTDI, though.
The $__ option seems a lot better to me, because there's no syntatical
reason against self-reference. ($^R for return might be a better name --
unless we've already used that for somthing else. Nope.)
Oh, here's an idea WRT extending the concept to cover both scalar and list
assignment: Have $^R be the return in scalar context, and @^R be the return
in list context. If @^R is unset, then a one-element list of $^R is returned.
-=- James Mastros
--
"My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers
fought, land where our King was shot -- from every building top, let freedom
happen!"
-=- Monique, Sinfest[.net]
AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
I recalled hearing about a language where
you set the return value of a function by
assigning to the name of the function within the function body,
Fortran and Pascal do that. Maybe others.
It would mean that
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
But that raises a potential conflict with another proposed magical
meaning of the subname within the sub: as a label for the beginning
of the sub. I.e.
sub foo {
bar();
}
is effectively
sub foo {
foo:
bar();
}
so that, for example, redo works kinda like the perl5 goto foo:
sub foo {
bar();
redo; # which is shorthand for:
redo foo; # like goto foo;
}
Proposals along these lines came up in the thread "$a in @b",
in the subsequent discussion of RFC 199, and probably in other
threads.
--
John Porter
A pessimist says the CPU is 50% utilized.
An optimist says the CPU is 50% unutilized.
A realist says the network is the bottleneck.
Re: assign to magic name-of-function variable instead of return
David L. Nicol wrote:
To answer my own question, the thing I found annoying about the syntax
when it was shown to me was that it seemed to break portability: you can't
cut from a function called A that returns something by assigning to A and
paste into a function called B to get the same functionality.
Maybe that's a good thing, by discouraging cargo-culting.
Another issue is, what is the scope of the symbol?
AFAICT, it can't be lexical and it can't be dynamic.
The former, because it can't be closed over:
sub foo {
return sub {
foo = 5;
}
}
$cr = foo();
$cr-(); # what just happened?!
And it being dynamic is problematic too:
sub foo {
foo = 4; # supposed to work, but...
}
foo = 6; # makes no sense!
make $__ mean "An alias for the
L-value of what the subroutine return value will get assigned to, or
${undef} if we're not invoked as an R-value."
I think that's unnecessarily baroque. Just let $__ be an alias
to the return value stack, the place where return() puts its
args anyway. In fact, shouldn't it be @__ ?
Too bad it's too late to write an RFC...
--
John Porter
A pessimist says the CPU is 50% utilized.
An optimist says the CPU is 50% unutilized.
A realist says the network is the bottleneck.
Re: assign to magic name-of-function variable instead of return
On Fri, Feb 02, 2001 at 08:09:36AM -0500, Charles Lane wrote: Peter Scott [EMAIL PROTECTED] wrote: At 07:12 PM 2/1/01 -0600, David L. Nicol wrote: I recalled hearing about a language (was it java?) where you set the return value of a function (was it VB?) by assigning to the name of the function within the function body, so the last line would be fname=rval; or fname could be used instead of rval all through it. Ah, an homage to Pascal :-) More like Fortran: REAL FUNCTION FOO(A) REAL A C FOO = 2*A+3 RETURN END ^^^ note exactly 7 spaces... And I think Fortran has a better claim to priority ;) And then there's Parse::RecDescent Abigail
Re: assign to magic name-of-function variable instead of return
On Thu, Feb 01, 2001 at 07:12:31PM -0600, David L. Nicol wrote:
Looking over some C code of the form
int fname(char *param){
int rval;
...
return(rval);
}
I recalled hearing about a language (was it java?) where
you set the return value of a function (was it VB?) by
assigning to the name of the function within the function body,
so the last line would be
fname=rval;
or fname could be used instead of rval all through it.
This obviously allows the compile-time optimization of using the
lvalue the function will be getting assigned to directly, one fewer
temporary storage space, as well as saving keystrokes.
Did anyone ever (before) suggest adding this to perl? It would mean
that
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
Does that mean there's going to be a @__ as well, for uses in list context?
If so, what happens with:
sub some_sub {
@__ = qw /foo bar baz/;
}
my $fnord = some_sub;
If there isn't going to be a @__ of some sorts, how is the case of the sub
being called in list context going to be handled?
Abigail
assign to magic name-of-function variable instead of return
Looking over some C code of the form
int fname(char *param){
int rval;
...
return(rval);
}
I recalled hearing about a language (was it java?) where
you set the return value of a function (was it VB?) by
assigning to the name of the function within the function body,
so the last line would be
fname=rval;
or fname could be used instead of rval all through it.
This obviously allows the compile-time optimization of using the
lvalue the function will be getting assigned to directly, one fewer
temporary storage space, as well as saving keystrokes.
Did anyone ever (before) suggest adding this to perl? It would mean
that
sub subname(proto){
# in here, the bareword "subname" is a magic
# alias for the lvalue this routine is getting
# assigned to, if any.
}
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"gorkulator borked. Please investigate."
Re: assign to magic name-of-function variable instead of return
"David L. Nicol" wrote:
We could even define a new line noise variable which could hold the
results of the last name-of-function subroutine that was not invoked
as an rvalue (I nominate $__ ); make such an invokation a warning-level
offense; and make $__ visibility/localization compatible with recursion.
To answer my own question, the thing I found annoying about the syntax
when it was shown to me was that it seemed to break portability: you can't
cut from a function called A that returns something by assigning to A and
paste into a function called B to get the same functionality. So a way
to have the feature (direct assignment to external lvalue) and maintain
portability might be to forget about magic names and just make the new
LNV (which I am calling $__ in this thread) mean "An alias for the
L-value of what the subroutine return value will get assigned to, or
${undef} if we're not invoked as an R-value." so ${undef} gets autolocalized
if used.
Re: assign to magic name-of-function variable instead of return
At 07:12 PM 2/1/01 -0600, David L. Nicol wrote: I recalled hearing about a language (was it java?) where you set the return value of a function (was it VB?) by assigning to the name of the function within the function body, so the last line would be fname=rval; or fname could be used instead of rval all through it. Ah, an homage to Pascal :-) -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of return
On Thu, Feb 01, 2001 at 07:36:59PM -0600, David L. Nicol wrote: So a way to have the feature (direct assignment to external lvalue) and maintain portability might be to forget about magic names and just make the new LNV (which I am calling $__ in this thread) mean "An alias for the L-value of what the subroutine return value will get assigned to A /much/ better syntax, IMHO. However, $__ must act sanely when we're called as an inner function (IE foo(bar(42))). And I always hated that about VB and Pascal -- you can assign to the magic variable, but can't modify it. And if you try, you don't error, you recruse. And perl will happily recruse until you run out of memory, and VB will give a stack overflow, and take down the IDE and your code unless you're careful. -=- James Mastros -- "My country 'tis of thee, of y'all i'm rappin'! Lan where my brothers fought, land where our King was shot -- from every building top, let freedom happen!" -=- Monique, Sinfest[.net] AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
