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
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
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
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
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
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 "$",
> 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 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
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
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
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
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
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:
:
> (?=...)
> (?!...)
> (?<=...)
> (?
> (?>...)
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
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
17 matches
Mail list logo
