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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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;
>
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
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
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
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
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
[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
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
[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
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
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
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
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
> >
> 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
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
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
> 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
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
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:
> > >
> >
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
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' }
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
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
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
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
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
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
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
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...
"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
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
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.
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
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
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
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
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
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*
59 matches
Mail list logo
