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
>
> '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
"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
Damian Conway wrote:
> Ken wrote:
>> The one thing I'm curious about is whether different syntactic
>> conventions affect the dispatcher or whether this is all just
>> sugar for a single dispatch.
>
> Multiple dispatch is certainly not (practically) implementable via single
> dispatch
"Bryan C. Warnock" wrote:
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='
That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b".
In SQL this is "$a IS NULL or $a >= $b".
- Ken
|
| > !< and !>
|
| How is !< different from >=?
]- the way of Expression or syntax-sugar if u like it :"), and is faster to
prononce :")
if, if not, unless
bigger, smaller, equal
less than or equal, bigger than or equal
not bigger, not smaller ...etc.
Personally I almost always make error wh
hi,
As we read in Damian Conway- Perl6-notes, there will by a var-iterator that
can be used to see how many times the cycle has been "traversed" i.e.
foreach my $el (@ary) {
.. do something
print $#; <--- print the index (or print $i )
}
shall we have :
foreach my $el (@ary) {
On Sunday 02 September 2001 01:47 pm, raptor wrote:
> As we read in Damian Conway- Perl6-notes, there will by a var-iterator
> that can be used to see how many times the cycle has been "traversed" i.e.
>
> foreach my $el (@ary) {
>.. do something
> print $#; <--- print the index (or
On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote:
>Sterin, Ilya <[EMAIL PROTECTED]> writes:
>>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>
>>> How is !< different from >=?
...
>It's the same number of characters. How can it be more convenient?
Why is it ">=" and not "=>"? Why "=<" and no
> -Original Message-
> From: raptor [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 02, 2001 1:47 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: LangSpec: Statements and Blocks [first,last]
>
>
> hi,
>
> As we read in Damian Conway- Perl6-notes, there will by a
>
On Sunday 02 September 2001 12:48 am, Uri Guttman wrote:
>
> i don't consider sort/map/grep blocks to be basic like the others. also
> sort/map can take espressions which is a different syntax.
Yes, I'm not addressing sort/map/grep/do as much as demonstrating a block
that appears in one of those
Bart Lateur <[EMAIL PROTECTED]> writes:
> Why is it ">=" and not "=>"?
Because in English, it's "less than or equal to" not "equal to or less
than," I presume.
> Simply trying to remember the order of characters might be (a bit of) a
> pain. That problem doesn't exist with "!<" and "!>".
Every
> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 02, 2001 8:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: !< and !>
>
>
> Bart Lateur <[EMAIL PROTECTED]> writes:
>
> > Why is it ">=" and not "=>"?
>
> Because in English, it's "less than or equ
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
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
# -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
"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
I hereby dub all the individual pieces of the intepreter as Parroty Bits.
--
Bryan C. Warnock
[EMAIL PROTECTED]
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
# -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
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
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, 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 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
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
# -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
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
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 Sunday 02 September 2001 08:18 pm, Michael G Schwern wrote:
> On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
> >
> > The following parses, but doesn't do anything, including warn.
> >
> > my $a = sub ($) { print };
>
> Wa
On Sunday 02 September 2001 06:27 pm, raptor wrote:
> ]- yep I didn't thougth about that I can be sure I'm at the last
> iteration only with some sort of 'callback' which will be called at the
> exit of the loop... but not as some sort of generalised-check condition..
Umm, it's simpler than t
On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> Are prototypes going to be checked at runtime now?
For methods, at least. Dunno about subs, that's Larry's call. I could make
a good language case for and against it. It adds overhead on sub calls,
which is a bad thing generally. (I'd be OK with the
On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I could make
> a good language case for and against it. It adds overhead
A thread from last July, WRT bug ID 2717.003 [1], suggested that we may
want to revisit the behavior of flow control expressions within the context
of a subroutine.
The current behavior is to find the closest (labelled) enclosing loop
(dynamically, not lexically), and treat that as the ta
Are prototypes going to be checked at runtime now?
The following parses, but doesn't do anything, including warn.
my $a = sub ($) { print };
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> Are prototypes going to be checked at runtime now?
>
> The following parses, but doesn't do anything, including warn.
>
> my $a = sub ($) { print };
Warning because you said you take an argument and then did nothing
with it...
| I don't know if (and if so, how) you would see if you were on the last
| iteration. (And would that be last, as in the very last argument passed
in,
| or last, as in you're not going to iterate again?)
]- yep I didn't thougth about that I can be sure I'm at the last
iteration only with some
# -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
37 matches
Mail list logo
