# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 1:37 PM
# To: Brent Dax
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# On Sun, 2 Sep 2001, Brent Dax wrote:
# >
# > Perhaps I wasn't entir
On Sun, 2 Sep 2001, Brent Dax wrote:
>
> Perhaps I wasn't entirely clear. I'm suggesting array-of-symbol-tables
> instead of array-of-arrays.
It is right now in perl 5, and that isn't changing. How do you think
string eval finds lexicals in scope by name now? :)
On Sun, 2 Sep 2001, Brent Dax wrote:
> Okay, I forgot to account for the fact that we'd have to increment the
> refcount for every inner scope a my() variable is referred to in.
> That's not terribly hard, is it?
I have no idea what you're talking about here. You asked if it was
possible to fak
# -Original Message-
# From: Sam Tregar [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 1:23 PM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
# On Sun, 2 Sep 2001, Brent Dax wrote:
#
# > but in that case the inner my($x) could be
Brent Dax wrote:
> Perl, however, is such a dynamic language you can't do a lot of that
> resolution at compile-time. What happens when I say:
> $x="foo";
> $::{"x"}=\"bar";
> print $x;
Just so we're clear, $x is a global variable -- there's only
one $x and it never goes
On Sun, 2 Sep 2001, Brent Dax wrote:
> but in that case the inner my($x) could be translated to
> temp($MY::x)--the behavior is basically the same. (Actually, if pads
> are replaced with stashes, is there any situation where my($x) can't be
> translated to temp($MY::x)? Hmmm...)
Closures, for
# -Original Message-
# From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
# Of Ken Fox
# Sent: Sunday, September 02, 2001 8:49 AM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# Brent Dax wrote:
# > Is there any real reason my() varia
I hereby dub all the individual pieces of the intepreter as Parroty Bits.
--
Bryan C. Warnock
[EMAIL PROTECTED]
"Bryan C. Warnock" wrote:
> No. We're optimizing on what we know at the time.
Um, it looked like you were generating a graph with all possible
optimizations inserted. At what point do you commit to an optimization?
If you only commit at run-time, you need to do a *lot* of state
management. It se
# -Original Message-
# From: Simon Cozens [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 4:34 AM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
#
# On Sun, Sep 02, 2001 at 03:13:09AM -0700, Brent Dax wrote:
# > Is there any real
On Sunday 02 September 2001 12:21 pm, Ken Fox wrote:
> The idea of inserting "optimization ops" seems silly too. It would
> be faster to just replace the definition of the sub whenever the
> sub changes. Perl 6 subs are just as fast as ops.
Except not every optimization is 'sub' oriented. Optimi
Wizard wrote:
> Johan Vromans wrote:
> > 'use constant FOO => "foo"' could add some magic to never let FOO
> > being redefined (not a bad coice for a constant).
>
> I like this idea best (for now). Perhaps 'constant sub foo' or 'sub
> foo:constant'?
I wouldn't consider this an optimization. Perl
Brent Dax wrote:
> Is there any real reason my() variables are stored in a pad instead
> of a symbol table?
Simon already told you why a pad is used.
But I think you misunderstand what a symbol table is. Variables
aren't *stored* in the symbol table. Only the definitions and storage
locations of
On Son, 02 Sep 2001, Brent Dax wrote:
>
>
> Currently, in Perl 5, my() variables are stored in a totally separate
> way from normal our()/local() variables, in an array-of-arrays
> structure. This means that my() variables are second-class citizens.
> The opcodes to look up a my() variable are
On Sun, Sep 02, 2001 at 03:13:09AM -0700, Brent Dax wrote:
> Is there any real reason my() variables are stored in a pad instead of a
> symbol table?
Recursion.
> It also seems like it would allow us to implement 'my sub'.
There's nothing stopping us implementing my sub now, other than wranglin
On Sat, Sep 01, 2001 at 03:29:23PM -0400, Bryan C. Warnock wrote:
> 30 -> store
>
> plus a bunch of null ops.
Not strictly true. Constant folding is done by running the interpreter on a
tiny portion of the opcode tree and splicing the result in. No null ops there.
> sub foo {
> no op
>
> 'use constant FOO => "foo"' could add some magic to never let FOO
> being redefined (not a bad coice for a constant).
>
> -- Johan
I like this idea best (for now). Perhaps 'constant sub foo' or 'sub
foo:constant'? By doing it that way, it is apparent to both Perl and the
developer that this i
Currently, in Perl 5, my() variables are stored in a totally separate
way from normal our()/local() variables, in an array-of-arrays
structure. This means that my() variables are second-class citizens.
The opcodes to look up a my() variable are separate from the opcodes for
an our()/local() var
"Brent Dax" <[EMAIL PROTECTED]> writes:
> sub FOO {"foo"}
> print FOO;
>
> evaluating to:
>
> /-no--"foo"-\
> opt: FOO redefined? -< >---print
> \-yes-call FOO--/
'use constant FOO => "foo
19 matches
Mail list logo
