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't
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
The third value is a peek value. Do the runtime checking, but don't do
any magic variable stuff. As a matter of fact, don't run any user-code at
all. Simply return a true or false value if the arguments *would* match.
(This
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
The third value is a peek value. Do the runtime
checking, but don't do any magic variable stuff. As a
matter of fact, don't run any user-code at all. Simply
return a true
The only good justification I've heard for final is as a directive
for optimization. If you declare a variable to be of a final type, then
the compiler (JIT, or whatever) can resolve method dispatch at
compile-time. If it is not final, then the compiler can make no such
assumption because
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 hold of pictures
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
At 09:30 AM 9/4/2001 -0700, Hong Zhang wrote:
The only good justification I've heard for final is as a directive
for optimization. If you declare a variable to be of a final type, then
the compiler (JIT, or whatever) can resolve method dispatch at
compile-time. If it is not final, then
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 the scratchpad
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)
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;
}
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 some other
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., ignoring a package
Bryan wrote:
Er, scratch this. Blows up if the sub isn't prototyped. A much
*better* way is to make the prototype of any sub a property
(trait) of that sub. We can always query for a property.
This is possible now:
$foo = sub ($) { print hello world\n };
At 10:04 AM 9/5/2001 +1100, Damian Conway wrote:
Dan wrote:
Why not Cdelete? 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
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 placeholder with
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 get tricky.
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't safely
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 where things get
Bryan asked:
That would be:
given ( $a ) {
when /a/ : { foo($a); goto BAR }
when /b/ : { ... }
BAR: when /c/ : { ... }
...
}
If they were statements, wouldn't that be:
On Tuesday 04 September 2001 09:09 pm, Damian Conway wrote:
A Cwhen is a statement, just as an Cif or a Cwhile is a statement.
Okay, then I simply need to rethink/redefine how I'm defining a statement,
(which is currently in terms of the statement separator).
--
Bryan C. Warnock
[EMAIL
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 the cost
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 what
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
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
24 matches
Mail list logo
