Larry Wall:
# Me writes:
# : > Very nice (but, I assume you meant {$foo data})!
# :
# : I didn't mean that (even if I should have).
# :
# : Aiui, Mike's final suggestion was that parens end up
# : doing all the (ops data) tricks, and braces are used
# : purely to do code insertions. (I really li
> (?=...)
> (?!...)
> (?<=...)
> (?
> (?>...)
Yummy :)
I'd say this is about perfect. The look(ahead|behind)s, er,
look<:ahead|behind>s are used seldom enough that this is practical. And
it's I much clea[nr]er than that (?=...) crap
Me writes:
: > Very nice (but, I assume you meant {$foo data})!
:
: I didn't mean that (even if I should have).
:
: Aiui, Mike's final suggestion was that parens end up
: doing all the (ops data) tricks, and braces are used
: purely to do code insertions. (I really liked that idea.)
:
: So:
:
On Tue, Apr 23, 2002 at 09:28:29AM +1000, Andrew J Bromage wrote:
> G'day all.
>
> On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
>
> > 3) We're having a new rule--you may *not* take a continuation from
> > within an opcode function! This is probably one of those "Well, Duh!"
>
G'day all.
On Mon, Apr 22, 2002 at 04:31:32PM -0400, Dan Sugalski wrote:
> 3) We're having a new rule--you may *not* take a continuation from
> within an opcode function! This is probably one of those "Well, Duh!"
> things but better to have it up front.
I see why you say this, but I'm not su
Aaron Sherman writes:
: On Sun, 2002-04-21 at 10:59, Trey Harris wrote:
:
: > 0 has true
: >
: > my first reaction would be, "huh? Since when?"
:
: Dare I say... "now"? ;-)
:
: Sorry, someone had to say it.
:
: Personally, even though it sucks up namespace, I think what we're seeing
: here i
G'day all.
On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
> >> I've applied this, with the exception of the branch and bsr ops.
[...]
On Mon, Apr 22, 2002 at 11:01:35AM -0400, Dan Sugalski wrote:
> The branches are relative to the current PC, the jumps take
> absolute addresse
Dan Sugalski:
# Okay, I've been thinking about subroutines lately. A lot. I had
# planned on putting them off a bit until we'd gotten scratchpads and
# globals done, but I thin I'd as soon get this off for discussion, so
# maybe we can have the rough edges worked out by the time we have
# hash
Okay, I've been thinking about subroutines lately. A lot. I had
planned on putting them off a bit until we'd gotten scratchpads and
globals done, but I thin I'd as soon get this off for discussion, so
maybe we can have the rough edges worked out by the time we have
hashes.
Subroutines, genera
On Mon, 2002-04-22 at 14:18, Me wrote:
> > Very nice (but, I assume you meant {$foo data})!
>
> I didn't mean that (even if I should have).
>
> Aiui, Mike's final suggestion was that parens end up
> doing all the (ops data) tricks, and braces are used
> purely to do code insertions. (I really li
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
On Sat, 2002-04-20 at 14:33, Me wrote:
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
Very nice (but, I assume you meant {$foo data})! This does add another
special case to the regexp parser's handling of "$",
At 12:03 PM +1000 4/19/02, Andrew J Bromage wrote:
>G'day all.
>
>On Thu, Apr 18, 2002 at 09:09:59PM -0400, Dan Sugalski wrote:
>
>> I've applied this, with the exception of the branch and bsr ops. At
>> the moment, I agree--I can't see any case where "if" or "gte" needs
>> to have a variable t
I don't have the time right now to do this myself, so here is a simple
idea to evaluate.
Currently, the computed goto decode and dispatch is essentially:
goto *ops_addr[ *cur_opcode ];
Now a big part of the gain of the prederef runops core comes from decoding each
op once instead of each time
On Sat, 2002-04-20 at 05:06, Mike Lambert wrote:
> > He then went on to describe something I didn't understand at all.
> > Sorry.
>
> Few corrections to what you wrote:
>
> To avoid the problem of extending {} to support new features with a
> character 'x', without breaking stuff that might have
On Sun, 2002-04-21 at 10:59, Trey Harris wrote:
> 0 has true
>
> my first reaction would be, "huh? Since when?"
Dare I say... "now"? ;-)
Sorry, someone had to say it.
Personally, even though it sucks up namespace, I think what we're seeing
here is a need for more than one keyword that are s
Two more problems found in string.c; these relate to the creation of
temporary strings to hold results of transcoding, in string_concat and
string_compare.
As per the latest (I think) decision from Dan ("Avoiding the deadlands", 9th
April: http://www.mail-archive.com/perl6-internals@perl.org/msg0
17 matches
Mail list logo
