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"

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: Really auto autoloaded modules

Well, I have two ideas kind of related to this subject, not very directly, but... Jarkko Hietaniemi wrote: > A gut feeling that I have is we can't simply go by interface 'names', > be they just simple names of funtions/methods or their full 'signatures' > (let us not even start on (1) how difficu

Re: Really auto autoloaded modules

Branden wrote: > > I really would suggest a close look at CORBA's IDL. I don't know if it can > handle not-objects, as I'm sure it's desired. But I think having CORBA & IDL > support will be certainly a need in Perl6, as it was stated this was one of > the objectives behind making strong-typing p

Re: JWZ on s/Java/Perl/

Piers Cawley wrote: >"Branden" <[EMAIL PROTECTED]> writes: >> Of course, C++ has no GC, which is a good thing, but you can always >> fake it with Refcounts, which is much more efficient, and easily >> feasable with C++. > >Err... current research shows that the refcount approach is one of the >slo

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"

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: JWZ on s/Java/Perl/

"Branden" <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >"Branden" <[EMAIL PROTECTED]> writes: > >> Of course, C++ has no GC, which is a good thing, but you can always > >> fake it with Refcounts, which is much more efficient, and easily > >> feasable with C++. > > > >Err... current researc

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: Really auto autoloaded modules

On Mon, Feb 05, 2001 at 09:15:45AM -0200, Branden wrote: > Well, I think this could be handled by Perl itself. I don't know if there's > a way of doing it directly with CPAN, but I think it should be independent > of CPAN, since there could be proprietary modules, that someone would like > to expo

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

module versions coexistence in same program

Dave Storrs <[EMAIL PROTECTED]> writes: > > On Fri, 2 Feb 2001, Garrett Goebel wrote: > > $Foo::VERSION eq 1.00 > | > | $Foo::VERSION eq 2.00 > | | > Bar Baz > \ / > My::Module > > Ideally, it should be perfectly legit to have multiple > versions of a given module on your system, whic

Re: Really auto autoloaded modules

Jonathan Scott Duff wrote: > If the proprietary modules were kept in a CPANish structure, then they > could just point CPAN.pm at the machine with that structure. CPAN.pm > could also be modified such that the user gets to tell it where to > look in detail (e.g., in some directory rather than on

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"

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"

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: Really auto autoloaded modules

At 02:17 PM 2/5/2001 -0200, Branden wrote: > > I think that, if you want this behavior, a module that implements it > > would be just fine. (Why muck with "use"?) To use a module name > > that seems like it could fit this purpose: > > > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }

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: Really auto autoloaded modules

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 02:17 PM 2/5/2001 -0200, Branden wrote: > > > I think that, if you want this behavior, a module that implements it > > > would be just fine. (Why muck with "use"?) To use a module name > > > that seems like it could fit this purpose: > > > > >

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"

> 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: Really auto autoloaded modules

David Grove wrote: > Please excuse me if I'm not up to date in this thread. I'm going on this > posting only. > > Although I'd agree with you about the security, Dan, this kind of remote > processing would, I think, be useful in my case as well, although at a > minimum it should be a non-default o

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"

> 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: Really auto autoloaded modules

At 11:08 AM 2/5/2001 +, David Grove wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > At 02:17 PM 2/5/2001 -0200, Branden wrote: > > > > I think that, if you want this behavior, a module that implements >it > > > > would be just fine. (Why muck with "use"?) To use a module name > >

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"

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"

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"

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

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: Really auto autoloaded modules

Dan Sugalski wrote: > > > > The parser needs to have it in a standard system-wide place. > > > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one > >wins? The file could be named AutoUse.pm or something. > > That strikes me as very much too high level a thing. I'm figuring the

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"

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"

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"

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"

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

End-of-scope actions, redux.

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. Perl 6 ought to provide universal exit mechanisms for an

Re: Really auto autoloaded modules

On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote: > At 02:17 PM 2/5/2001 -0200, Branden wrote: > > > I think that, if you want this behavior, a module that implements it > > > would be just fine. (Why muck with "use"?) To use a module name > > > that seems like it could fit this purp

a name for the currently executing sub

James Mastros wrote: > > At least it's independent of the sub's name. I wish this could be > > extended to doing recursive calls without having to say the subs own > > name, again. > I agree, making the magic variable be the name of the sub is a bad idea. > > Your idea for a name for the current

Re: Really auto autoloaded modules

At 12:54 PM 2/5/2001 -0800, Nathan Wiger wrote: >Dan Sugalski wrote: > > > > > > The parser needs to have it in a standard system-wide place. > > > > > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one > > >wins? The file could be named AutoUse.pm or something. > > > > That str

Re: a name for the currently executing sub

At 04:59 PM 2/5/2001 -0600, David L. Nicol wrote: >James Mastros wrote: > > > > At least it's independent of the sub's name. I wish this could be > > > extended to doing recursive calls without having to say the subs own > > > name, again. > > I agree, making the magic variable be the name of the

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: Really auto autoloaded modules

Dan Sugalski wrote: > > >Regarding #1, if there's no need to make it extensible by users, why > >have a file at all? This shouldn't change after Perl is built, right? > >And all of the stuff that's going to be "autoloaded" in this way will be > >included in the core dist, right? Sounds like some

Re: Really auto autoloaded modules

At 09:58 PM 2/5/2001 +, Tim Bunce wrote: >On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote: > > At 02:17 PM 2/5/2001 -0200, Branden wrote: > > > > I think that, if you want this behavior, a module that implements it > > > > would be just fine. (Why muck with "use"?) To use a modu

Re: Really auto autoloaded modules

use autoload { Bar => 'http://www.cpan.org/modules/Bar', MD5 => boogedyboogedyboogedyboo }, { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION => 2, MD5 => dfasgjlkndakjargjbg245098t4lkjng }; Security mechan

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: Really auto autoloaded modules

On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote: >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }, >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION => >>2 }; >> >>Very good idea indeed!!! Append the wishlist to add this module to perl6's >>standard

Re: Really auto autoloaded modules

On Tue, Feb 06, 2001 at 12:49:28AM +0100, Bart Lateur wrote: > On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote: > > >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }, > >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION => > >>2 }; > >> > >>Very good

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: Really auto autoloaded modules

On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote: > > > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }, > > > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION => > >2 }; > > > >Very good idea indeed!!! Append the wishlist to add this module to perl6's

Re: a name for the currently executing sub

Dan Sugalski wrote: > >IMO the name of the currently executing sub should be accessed via an > >extention to C. > > > > caller{subname} > > Oh? What prints, then? > >$foo = sub {print caller{subname}}; >$foo->(); something like CODE(0x80cfd7c) since we don't have a better name

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: a name for the currently executing sub

At 06:35 PM 2/5/01 -0600, David L. Nicol wrote: >--- warning --- bad idea follows --- You're not kidding. >Are we willing to let user-code use codereftagstrings abckwards yet? > >perl -le '$a = \(1..4); $tagstring="$a"; print @{$tagstring}' > >We would eliminate all strings matching /^[A-Z]\(0x

Re: Really auto autoloaded modules

Dan Sugalski writes: > I'm fine with silly things, it's dangerous things I don't much care for. > Which isn't to say I'm against loading remote program code, I just think > this isn't the way to do it. use autoload { Bar => 'uddi://blah/some/Bar' }; (here I take a big swill from the web servic

Re: Really auto autoloaded modules

At 07:02 PM 2/5/2001 -0700, Nathan Torkington wrote: >Dan Sugalski writes: > > I'm fine with silly things, it's dangerous things I don't much care for. > > Which isn't to say I'm against loading remote program code, I just think > > this isn't the way to do it. > >use autoload { Bar => 'uddi://bla

Can we try autoloading again?

We seem to have gotten rather off the point. We will have some method to serialize chunks of perl code and the associated variables and freeze them off somewhere (disk, sockets, databases, whatever) so hopefully that'll be enough to build on. Can we take a shot at the things that we'd need to

Re: a name for the currently executing sub

At 06:35 PM 2/5/2001 -0600, David L. Nicol wrote: >Are we willing to let user-code use codereftagstrings abckwards yet? Yes, we are. >We would gain C style casting capability, with all the evil that brings >with it, including the ability to bittwiddle perl structures from >within perl, which is