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*
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
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
Dan Sugalski wrote:
> The vtable stuff won't be exposed outside the core. This means embedding
> programs and extensions will *not* be using it. Generally speaking, it'll
> be opcode functions only that'll be hitting the vtables.
What? I thought it would replace most of sv_... functions (that of
Branden wrote:
[...]
>
> I also don't see how it wouldn't bang badly if we get an incorrect PMC. How
> would we extract the 5th element of a scalar? And how would we read one line
> out of an array? Sum two hashes? I think having only one vtable for all
> would only put a burden on who implements
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.
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
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
Edwin Steiner wrote:
> Branden wrote:
> [...]
> >
> > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
How
> > would we extract the 5th element of a scalar? And how would we read one
line
> > out of an array? Sum two hashes? I think having only one vtable for all
> > would o
Branden wrote:
>
> Edwin Steiner wrote:
> > Branden wrote:
> > [...]
> > >
> > > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
> How
> > > would we extract the 5th element of a scalar? And how would we read one
> line
> > > out of an array? Sum two hashes? I think having
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
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
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
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
Edwin, good that we agree. I have some questions for you:
Edwin Steiner wrote:
> Branden wrote:
> > but would certainly make the program die, what could be avoided if SV*,
AV*,
> > HV* and so on are different of each other, and casts are not required
among
> > them, as is done today in Perl 5,
>
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' }
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
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:
> > >
> >
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
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
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
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
> 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
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
> >
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
> 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
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
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
There are two possible things that could happen when you say:
$a = $b;
@a = @b; # or
%a = %b;
These two things are assignment and aliasing. Assignment happens when the
value of the rvalue is fetched (by a vtable correspondent FETCH operation),
and this value is stored in the lvalue (
On Mon, Feb 05, 2001 at 03:35:18PM -0200, Branden wrote:
> How will this problem be solved, and, more generally, how will aliasing take
> place in perl6?
This is perhaps a bad way to answer the question, but:
I'm hoping that the vtable PDD should be around in a few days (Pssst, Dan!)
and it migh
Branden wrote:
[...]
> Edwin Steiner wrote:
[...]
> > Different pointer types also make coding harder when there is no
> > need to make a difference between object types. (When you just pass
> > something on, for example.)
> >
>
> I actually see it as strong typing, which I believe is good on the
At 12:33 PM 2/5/2001 -0600, Garrett Goebel wrote:
>From: Edwin Steiner [mailto:[EMAIL PROTECTED]]
> >
> > Branden wrote:
> > >
> > > and the other thing is that creating a
> > > vtable for another type would break all existing types.
> > >
> > > Example: suppose we want compiled regexes (qr/^xyz$/
At 07:11 PM 2/5/2001 +0100, Edwin Steiner wrote:
>Branden wrote:
>[...]
> > Edwin Steiner wrote:
>[...]
> > > I wonder how many data types will directly rely on vtable layout. I would
> > > think all data types implemented outside the core will use an additional
> > > level of indirection (tie-lik
At 05:00 PM 2/5/2001 -0200, Branden wrote:
>Garrett Goebel wrote:
> > I thought one of the benefits of vtables was to facilitate extending
>support
> > for new types?
> >
> > Does RFC 32 have any place in this discussion?
>
>Yes!!!
No. It's far too high-level a sort of thing for vtables, which ar
Dan Sugalski wrote:
> Nope. (Well, sort of, but there are days when I'm a Coder Of Very Little
> Brain, so take it with however much salt as need be) I want to isolate us
> from vtables for another reason entirely.
>
> Binary compatibility.
>
> If we isolate things that don't need to deal with vta
From: Edwin Steiner [mailto:[EMAIL PROTECTED]]
>
> Branden wrote:
> >
> > and the other thing is that creating a
> > vtable for another type would break all existing types.
> >
> > Example: suppose we want compiled regexes (qr/^xyz$/)
> > to have its own vtable so that we could inspect them
> >
Edwin Steiner wrote:
> [...]
> As to strong typing: I don't expect that it will be possible on the
> really low level. Of course it's no problem when calling C-functions
> with arguments on the C-stack. But if you have a virtual stack machine
> (Perl stack) or even convert to machine code (TIL) yo
Garrett Goebel wrote:
> I thought one of the benefits of vtables was to facilitate extending
support
> for new types?
>
> Does RFC 32 have any place in this discussion?
Yes!!!
> Per RFC 32: A method of allowing foreign objects in perl
> >
> > Since writing half a zillion perl2WhoKnowsWhat modul
At 04:43 PM 2/5/2001 -0200, Branden wrote:
>Edwin Steiner wrote:
I snipped a bunch of stuff here. Generally speaking low-level perl
variables will share a single base structure, the PMC, which will be the
same for hashes, arrays, lists, and scalars. (I'm not sure whether
filehandles and dirhan
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 05:24 PM 2/5/2001 -0200, Branden wrote:
>I just expect consistency, e.g. nothing like sv_xyz, SvXYZ, SV_XYZ, SVt_XYZ
>and I wonder what else there would be!!! (damn XS!)
Heh. Don't worry--I've been bitten by that more often than I care to think
about. (I hate dealing with hashes in XS, since
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
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
[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
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
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
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
[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
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
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
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
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;
>
Okay, here's the VTABLE PDD. Comments, please. (As if there's any worry
about not having any :)
-Snip here--
=head1 TITLE
Common vtable format for all variables
=head1 VERSION
=head2 CURRENT
Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
Class: Internals
PDD Numbe
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
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
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
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
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
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
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
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
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
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 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
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 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, 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
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
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
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 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
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 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
77 matches
Mail list logo
