Re: assign to magic name-of-function variable instead of "return"

Damian Conway <[EMAIL PROTECTED]> writes: > sub { > ... > return $yadda_yadda; > } > always { close F } Let's try not to fall into the Java trap. If exception handling gets too wordy, programmers will try to reduce the overhead by combining many stat

Re: assign to magic name-of-function variable instead of "return"

I wrote: > 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 D

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 agr

Re: assign to magic name-of-function variable instead of "return"

On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote: > sub has_post_blocks{ > my $i = 3; > post { print "i ended up as $i"}; > my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small"; > my $j = 2; > post {

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 make

Re: assign to magic name-of-function variable instead of "return"

John Porter wrote: > 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. So if a post{} block could appear anywhere inside a block,

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

Re: assign to magic name-of-function variable instead of"return"

> 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 c

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 { >

Re: assign to magic name-of-function variable instead of "return"

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 { b

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" itse

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). Funny, during the perl6 RFC period, during the discussion of the exception handling RFCs 88 and 119

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(); > close F; > } > } > > 'prog1' e

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 e

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

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() > } Would the POST be executed if the open fails? Wh

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() >} >post readit { >close F; >} The connection between these two things is

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 sho

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

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 m

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 m

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 RF

Re: assign to magic name-of-function variable instead of "return"

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

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 su

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

Re: assign to magic name-of-function variable instead of "return"

On Tue, Feb 06, 2001 at 08:25:17AM +1100, 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; >

Re: assign to magic name-of-function variable instead of "return"

On Tue, Feb 06, 2001 at 08:25:17AM +1100, Damian Conway wrote: > >return ( $stuff, $morestuff, $whatever ) always close F; > > I *really* like that keyword. what's the difference between this and - close F; return ($stuff, $morestuff, $whatever); Just curious, missed the discussion so f

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 blo

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 co

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 > C, though I would much prefer a more generic name, such as > C. Both of the exception handling RFCs discuss an "always" b

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

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 (wnat

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"

On Mon, Feb 05, 2001 at 12:29:34PM -0500, John Porter wrote: > James Mastros wrote: > > 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

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 do

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 > C, though I would much prefer a more generic name, such as > C. But in some sense it's much more like the file-level EN

Re: assign to magic name-of-function variable instead of "return"

> 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

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() > } > post readit { > close F; > } Really? Are lexicals in the sub visible in the post handler? (Of course

Re: assign to magic name-of-function variable instead of "return"

> I see this all the time. What would fit the bill is to have something > like a C block for subs; they get called during the same > phase as destructors of objects going out of scope. > > sub readit { > open F, "< $f" ... > scalar() > } > c

Re: assign to magic name-of-function variable instead of "return"

James Mastros wrote: > 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 see

Re: assign to magic name-of-function variable instead of "return"

On Mon, Feb 05, 2001 at 11:39:47AM +0100, Bart Lateur wrote: > What do you mean, "nope"? It *is* in use. The (?{...}) > embed-perl-code-in-a-regex feature sets it. With a return value. Hah. Oh. I wasn't at home, so I had to use the copy of perlvar on perldoc.org, which apparently isn't up-to-date

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 fo

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 camp

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

Re: assign to magic name-of-function variable instead of "return"

David L. Nicol wrote: >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. > >sub subname(proto){ ># in here, the bareword "subname" is a magic ># alias for the

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 Thu, Feb 01, 2001 at 07:12:31PM -0600, 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. > } It always confused me in Pascal

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.

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 tha

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 tha

Re: assign to magic name-of-function variable instead of "return"

On Sun, 4 Feb 2001 15:43:29 -0500, James Mastros wrote: >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.) What do you mean, "nope"? It *is*

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

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, Burrou

Re: assign to magic name-of-function variable instead of "return"

On Fri, Feb 02, 2001 at 05:01:29PM -0600, David L. Nicol wrote: > > A /much/ better syntax, in [John Mastros's] humble opinion. However, "James", BTW. (No, I don't really care.) > > $__ must act sanely when we're called as an inner function (IE foo(bar(42))). > if we allow $__ to have meaning mo

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 f

Re: assign to magic name-of-function variable instead of "return"

> > 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." > A /much/ better syntax, in [John Mastros's] humble opinion. However, > $__ must act sanely when we're called as an inner function (IE

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 nam

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

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

Re: assign to magic name-of-function variable instead of "return"

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

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-val

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

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

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 b