At 05:42 PM 9/12/2001 -0500, David L. Nicol wrote:
>Uri Guttman can see a day where:
> > python and ruby, etc. are
> > defaulting to using the parrot back end as it will be faster, and
> > compatible with perl etc. imagine the work reduction if all/most of the
> > interpreted languages can share o
Uri Guttman can see a day where:
> python and ruby, etc. are
> defaulting to using the parrot back end as it will be faster, and
> compatible with perl etc. imagine the work reduction if all/most of the
> interpreted languages can share one common back end.
What about the compiled ones? Did we c
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> > But surely %MY:: allows you to access/manipulate variables that are in
> > scope, not just variables are defined in the current scope, ie
> >
> > my $x = 100;
> > {
> > print $MY::{
At 12:13 AM 9/7/2001 -0400, Ken Fox wrote:
>Damian Conway wrote:
> > "3, 1, 3" is the correct answer.
>
>That's what I thought. Dan's not going to be happy. ;)
Well, it means a fetch by pad entry rather than use of a cached PMC
pointer, but that's OK by me.
I have a solution for this that I'm p
On Friday 07 September 2001 12:56 am, Ken Fox wrote:
> "Bryan C. Warnock" wrote:
> > Generically speaking, modules aren't going to be running amok and making
> > a mess of your current lexical scope - they'll be introducing, possibily
> > repointing, and then possibly deleting specific symbols
>
>
"Bryan C. Warnock" wrote:
> Generically speaking, modules aren't going to be running amok and making a
> mess of your current lexical scope - they'll be introducing, possibily
> repointing, and then possibly deleting specific symbols
How much do you want to pay for this feature? 10% slower code?
On Friday 07 September 2001 12:13 am, Ken Fox wrote:
> Damian Conway wrote:
> > Bzzzt! The line:
> >
> > %MY::{'$x'} = \$z;
> >
> > assigns a reference to $z to the *symbol table entry* for $x, not to $x
> > itself.
>
> So I should have said:
>
> %MY::{'$x'} = $z;
>
> That's pretty magic
Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x itself.
So I should have said:
%MY::{'$x'} = $z;
That's pretty magical stuff isn't it? Sorry I used the wrong syntax.
I'm just taking it from yo
On Thursday 06 September 2001 07:44 pm, Damian Conway wrote:
> Bzzzt! The line:
>
> %MY::{'$x'} = \$z;
>
> assigns a reference to $z to the *symbol table entry* for $x, not to $x
> itself.
So you're saying that the symbol table entry contains a reference to the
variable it represents? Oka
Bryan thought:
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x, $$y, $z\n"
>
> My $x container contains 1. ($x = 1)
> My $y container contains a ref to the $x container. ($x = 1, $y = \$x)
> My $z contai
On Thursday 06 September 2001 06:01 pm, Garrett Goebel wrote:
> From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > I think we have a language question... What should the following
> > print?
> >
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x
On Thursday 06 September 2001 05:52 pm, Ken Fox wrote:
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3
On Thursday 06 September 2001 08:53 am, Dave Mitchell wrote:
> But surely %MY:: allows you to access/manipulate variables that are in
> scope, not just variables are defined in the current scope, ie
>
> my $x = 100;
> {
> print $MY::{'$x'};
> }
>
> I would expect that to print 100, not 'undef'
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e.
Dan Sugalski wrote:
> On the other hand, if we put the address of the lexical's PMC into a
> register, it doesn't matter if someone messes with it, since they'll be
> messing with the same PMC, and thus every time we fetch its value we'll Do
> The Right Thing.
Hmm. Shouldn't re-binding affect onl
At 02:44 PM 9/6/2001 -0400, Ken Fox wrote:
>Could you compile the following for us with the assumption that
>g() does not change its' caller?
Maybe later. Pressed for time at the moment, sorry.
>What if g() *appears* to be safe when perl compiles the loop, but
>later on somebody replaces its' de
Dan Sugalski wrote:
> At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
> >You wrote on perl6-internals:
> >
> >get_lex P1, $x # Find $x
> >get_type I0, P1 # Get $x's type
> >
> >[ loop using P1 and I0 ]
> >
> >That code isn't safe! If %MY is changed at run-time, the
> >type
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > I think you're also overestimating the freakout factor.
>
> Probably. I'm not really worried about surprising programmers
> when they debug their code. Most of the time they've requested
> the surprise and will at least have a
At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
[stuff I snipped]
>I'm worried a little about building features with global effects.
>Part of Perl 6 is elimination of action-at-a-distance, but now
>we're building the swiss-army-knife-of-action-at-a-distance.
I don't know how much
Dan Sugalski wrote:
> I think you're also overestimating the freakout factor.
Probably. I'm not really worried about surprising programmers
when they debug their code. Most of the time they've requested
the surprise and will at least have a tiny clue about what
happened.
I'm worried a little abo
At 11:44 AM 9/6/2001 -0400, Ken Fox wrote:
>Yeah, I can see it now. Perl 6 has three kinds of variables:
>dynamically scoped package variables, statically scoped lexical
>variables and "Magical Disappearing Reappearing Surprise Your
>Friends Every Time" variables. Oh, and by the way, lexicals
>are
At 11:51 AM 9/6/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS>my $foo = 'a';
> DS>{
> DS> {
> DS>%MY[-1]{'$foo'} = 'B';
> DS>print $foo;
> DS> }
> DS> }
>
>explain %MY[-1] please.
>
>my impression
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS>my $foo = 'a';
DS>{
DS> {
DS>%MY[-1]{'$foo'} = 'B';
DS>print $foo;
DS> }
DS> }
explain %MY[-1] please.
my impression is that is illegal/meaningless in perl6. maybe you meant
something w
Dan Sugalski wrote:
> ... you have to take into account the possibility that a
> variable outside your immediate scope (because it's been defined in an
> outer level of scope) might get replaced by a variable in some intermediate
> level, things get tricky.
Other things get "tricky" too. How abou
At 02:19 PM 9/6/2001 +0200, Bart Lateur wrote:
>On Tue, 04 Sep 2001 18:38:20 -0400, Dan Sugalski wrote:
>
> >At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
> >>The main uses are (surprise):
> >>
> >> * introducing lexically scoped subroutines into a caller's scope
> >
> >I knew there was
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> "Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> > Consider it like, oh, PATH and executables:
> > `perl` will search PATH and execute the first perl
> > found, but 'rm perl' will not. It would only remove
> > a perl in my current scope..., er, dire
"Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> Consider it like, oh, PATH and executables:
> `perl` will search PATH and execute the first perl found, but 'rm perl' will
> not. It would only remove a perl in my current scope..., er, directory.
But surely %MY:: allows you to access/manipulate v
%MY:: manipulates my lexical pad. If, to resolve a variable, I have to
search backwards through multiple pads (that's a metaphysical search, so as
to not dictate a physical search as the only behavior), that's a different
beastie.
Consider it like, oh, PATH and executables:
`perl` will search
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> > One further worry of mine concerns the action of %MY:: on unintroduced
> > variables (especially the action of delete).
> >
> > my $x = 100;
> > {
> > my $x = (%MY::{'$x'} = \200, $
On Tue, 04 Sep 2001 18:38:20 -0400, Dan Sugalski wrote:
>At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
>>The main uses are (surprise):
>>
>> * introducing lexically scoped subroutines into a caller's scope
>
>I knew there was something bugging me about this.
>
>Allowing lexically scope
On Thursday 06 September 2001 06:16 am, Dave Mitchell wrote:
> One further worry of mine concerns the action of %MY:: on unintroduced
> variables (especially the action of delete).
>
> my $x = 100;
> {
> my $x = (%MY::{'$x'} = \200, $x+1);
> print "inner=$x, ";
> }
> print "outer=$x";
>
>
On Thursday 06 September 2001 07:15 am, David L. Nicol wrote:
> in file Localmodules.pm:
>
> use Pollutte::Locally;
> use Carp;
>
> and in blarf.pl:
>
> sub Carp {print "outer carp\n"};
sub frok { Carp(); }
>
> {
> use Localmodules.pm;
>
Damian Conway wrote:
> proper lexically-scoped modules.
sub foo { print "outer foo\n"};
{
local *foo = sub {print "inner foo\n"};
foo();
};
foo();
did what I wanted it to. Should I extend Pollute:: to make
this possible:
in fi
One further worry of mine concerns the action of %MY:: on unintroduced
variables (especially the action of delete).
my $x = 100;
{
my $x = (%MY::{'$x'} = \200, $x+1);
print "inner=$x, ";
}
print "outer=$x";
I'm guessing this prints inner=201, outer=200
As for
my $x = 50;
{
my $x =
[EMAIL PROTECTED] wrote:
> Clearly caller() isn't what we want here, but I'm not
> quite sure what would be the correct incantation.
I've always assumed that a BEGIN block's caller() will
be the compiler. This makes it easy for the compiler to
lie about %MY:: and use the lexical scope being compi
Dan Sugalski <[EMAIL PROTECTED]> wrote
> >my $x = 1;
> >{
> > my $x = 2;
> > delete $MY::{'$x'};
> > print $x;
> > $mysub = sub {$x};
> >}
> >
> >print $mysub->();
> >
> >People seem agreed that print $x should do the equivalent of
> > throw "lexical '$x' no longer in scope
At 01:45 PM 9/5/2001 +0100, Dave Mitchell wrote:
>can I just clarify something about delete:
>
>my $x = 1;
>{
> my $x = 2;
> delete $MY::{'$x'};
> print $x;
> $mysub = sub {$x};
>}
>
>print $mysub->();
>
>People seem agreed that print $x should do the equivalent of
> throw
can I just clarify something about delete:
my $x = 1;
{
my $x = 2;
delete $MY::{'$x'};
print $x;
$mysub = sub {$x};
}
print $mysub->();
People seem agreed that print $x should do the equivalent of
throw "lexical '$x' no longer in scope"
rather than printing 1, but what s
Garrett Goebel <[EMAIL PROTECTED]> wrote
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > sub Foo::import {
> > my %m = caller(1).{MY}; # or whatever
> > %m{'$x'} = 1;
> > }
...
> > sub f {
> > my $x = 9;
> > use Foo; # does $x become 1, or $x redefined, or runtime
> >
Ken Fox wrote:
> Modifying the caller's environment:
>
> $lexscope = caller().{MY};
> $lexscope{'&die'} = &die_hard;
>
> is especially annoying because it means that I can't
> trust lexical variables anymore.
You think you can trust them now? :-)
The PadWalker module (on CPAN) allows a su
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Dan concluded:
>> Certainly doable. Just potentially slow, which is what I'm worried
>> about. Making it not slow has both potential significant complexity
>> and memory usage. If we have to, that's fine. Just want to make
>> s
Damian wrote:
> In other words, everything that Exporter does, only with lexical
> referents not package referents. This in turn gives us the ability to
> easily write proper lexically-scoped modules.
Great! Then we don't need run-time lexical symbol table
frobbing. A BEGIN block can muck with it
At 10:23 PM 9/4/2001 -0400, Ken Fox wrote:
>Efficiency is a real issue! I've got 30,000 lines of *.pm in my
>latest application -- another 40,000 come from CPAN. The lines
>of code run a good deal less, but it's still a pretty big chunk
>of Perl.
>
>The thought of my app suddenly running slower (p
On Tuesday 04 September 2001 10:10 pm, Dan Sugalski wrote:
> At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
> >Yes, this is akin to redeclaring every lexical variable every time you
> >introduce a new scope. Not pretty, I know. But if you want run-time
> >semantics with compile-time resolu
Damian wrote:
> Dan wept:
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can't safely resolve at compile time wh
At 12:00 PM 9/5/2001 +1100, Damian Conway wrote:
>Dan concluded:
>
>> Certainly doable. Just potentially slow, which is what I'm worried
>> about. Making it not slow has both potential significant complexity
>> and memory usage. If we have to, that's fine. Just want to make
>> sure
At 08:59 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
>Yes, this is akin to redeclaring every lexical variable every time you
>introduce a new scope. Not pretty, I know. But if you want run-time
>semantics with compile-time resolution
That is exactly what it is, alas. If we allow lexicals to
On Tuesday 04 September 2001 08:32 pm, Dan Sugalski wrote:
> Absolutely nothing. The issue is speed. Looking back by name is, well,
> slow. The speed advantage that lexicals have is that we know both what pad
> a variable lives in and what offset in the pad it's living at. We don't
> have to do an
Dan concluded:
> Certainly doable. Just potentially slow, which is what I'm worried
> about. Making it not slow has both potential significant complexity
> and memory usage. If we have to, that's fine. Just want to make
> sure the cost is known before the decision's made. :)
I rather
At 07:24 PM 9/4/2001 -0400, Bryan C. Warnock wrote:
>On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> > Ah, but what people will want is:
> >
> >my $x = "foo\n";
> >{
> > my $x = "bar\n";
> > delete $MY::{'$x'};
> > print $x;
> >}
> >
> > to print foo. That's
At 10:34 AM 9/5/2001 +1100, Damian Conway wrote:
>Dan wept:
>
>> I knew there was something bugging me about this.
>>
>> Allowing lexically scoped subs to spring into existence (and
>> variables, for that matter) will probably slow down sub and
>> variable access, since we can
Dan wept:
> I knew there was something bugging me about this.
>
> Allowing lexically scoped subs to spring into existence (and
> variables, for that matter) will probably slow down sub and
> variable access, since we can't safely resolve at compile time what
> variable or sub
Dan sighed:
> >I don't understand why you think that's particularly wormy?
>
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things g
On Tuesday 04 September 2001 07:25 pm, Dan Sugalski wrote:
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things get tricky. Though I suppose we could
> put some sort of pl
At 10:04 AM 9/5/2001 +1100, Damian Conway wrote:
>Dan wrote:
>Why not C? It merely requires that the internals equivalent of:
[Snippy]
>I don't understand why you think that's particularly wormy?
Ah, but what people will want is:
my $x = "foo\n";
{
my $x = "bar\n";
delete $MY::
Dan wrote:
> At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >
> >So deleting it
> >would remove it from the scratchpad of &incr. But I would guess that
> >future calls to &incr would have to autovify $x in the scratchpad and
> >start incrementing it from 0. I.e., ignorin
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because so
Dave Mitchell asked:
> If there is to be a %MY, how does its semantics pan out?
That's %MY::. The colons are part of the name.
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
>The main uses are (surprise):
>
> * introducing lexically scoped subroutines into a caller's scope
I knew there was something bugging me about this.
Allowing lexically scoped subs to spring into existence (and variables, for
that matter)
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Thank-you. But I have to contend with the inflation of expectations.
DC> Last year I wow'd them with simple quantum physics. This year, I needed
DC> a quantum cellular automaton simulation of molecular thermodynamics
DC> written
Ken wrote:
> Damian Conway wrote:
> > It would seem *very* odd to allow every symbol table *except*
> > %MY:: to be accessed at run-time.
>
> Well, yeah, that's true. How about we make it really
> simple and don't allow any modifications at run-time to
> any symbol table?
At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > sub Bar::import {
> > my %m = caller(1).{MY}; # or whatever
> > delete %m{'$x'};
> > }
>
>hmm... when:
>
>{ my $x = 1; sub incr {$x++} }
>
>is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
>would remove it from t
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
>
> If there is to be a %MY, how does its semantics pan out?
>
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
IMO: Sets the value of the lexical $x i
If there is to be a %MY, how does its semantics pan out?
for example, what (if anything) do the following do:
sub Foo::import {
my %m = caller(1).{MY}; # or whatever
%m{'$x'} = 1;
}
sub Bar::import {
my %m = caller(1).{MY}; # or whatever
delete %m{'$x'};
}
sub f {
my $x =
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Can we have an example of why you want run-time
> symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime cate
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Dan revealed:
>> That's easy--you slip the pumpking or internals designer a 10-spot.
>> Amazing what it'll do... :)
DC> And how do you think I got five of my modules into the 5.8 core???
i heard it was blackmail. you got a hol
Damian Conway wrote:
> It would seem *very* odd to allow every symbol table *except*
> %MY:: to be accessed at run-time.
Well, yeah, that's true. How about we make it really
simple and don't allow any modifications at run-time to
any symbol table?
Somehow I get the feeling that "*very* odd" can'
Dan revealed:
> > How am I expected to produce fresh wonders if you won't let me
> > warp the (new) laws of the Perl universe to my needs?
> That's easy--you slip the pumpking or internals designer a 10-spot.
> Amazing what it'll do... :)
And how do you think I got five of my module
At 04:11 PM 9/4/2001 +1100, Damian Conway wrote:
>I would envisage that mucking about with symbol tables would be no more
>common in Perl 6 than it is in Perl 5. But I certainly wouldn't want to
>restrict the ability to do so.
>
>How am I expected to produce fresh wonders if you won't let me warp
> I haven't seen details in an Apocalypse, but Damian's
> Perl 6 overview has a bit about it. The Apocalypse
> specifically mentions *compile-time* scope management,
> but Damian is, uh, Damian. (DWIMery obviously. ;)
Hmm.
It would seem *very* odd to allow every symbol table *ex
I haven't seen details in an Apocalypse, but Damian's
Perl 6 overview has a bit about it. The Apocalypse
specifically mentions *compile-time* scope management,
but Damian is, uh, Damian. (DWIMery obviously. ;)
Is stuff like:
%MY::{'$lexical_var'} = \$other_var;
supposed to be a compile-time o
71 matches
Mail list logo
