In between attempting to get the new assembler up and running (currently
dealing with XS issues), Robert Spiers and I have come up with a new
make mechanism.
The syntax may change, and the build mechanism has a ways to go (It's
simply running one step at a time in order, no parallelism or multipl
> when matching against something like "foo\nwiffle\nbarfoo\n"
>/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
>/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?
On Tue, Apr 23, 2002 at 11:11:28PM -0500, Me wrote:
> Third, I was thinking that having perl 6 regexen have /s on
> by default would be easy for perl 5 coders to understand;
> not too hard to get used to; and have no negative effects
> for existing coders beyond getting used to the change.
I'm ju
> > : I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of "match anything but
newline" into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor s
> : I'd expect . to match newlines by default. For a . that
> : didn't match newlines, I'd expect to need to use [^\n].
>
> But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then whe
On Tue, Apr 23, 2002 at 08:54:56PM -0700, Steve Fink wrote:
> (And that 3 should really be 4; the computed goto should > just be
> another option IMHO.)
Maybe not so humble: here's a patch to disable the default computed
goto core, so you can compare all four cores (assuming the previous
patch is
Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state
This is a rather clumsy patch to make prederef mode work without
needing to be compiled as a shared library. In fact, it prevents it
from being used as a shared library (but it's trivial to revert to the
former behavior; see the patch.)
Anyone who wishes is welcome to figure out exactly what's go
Andrew J Bromage:
# On Tue, Apr 23, 2002 at 01:18:23PM -0700, Brent Dax wrote:
#
# > Three questions:
# >
# > 1. Which'll be faster?
#
# It depends on the application, but my money is on mutable
# strings built on top of an immutable buffer. That's based on
# looking at my own string-based P
G'day all.
On Tue, Apr 23, 2002 at 01:18:23PM -0700, Brent Dax wrote:
> Three questions:
>
> 1. Which'll be faster?
It depends on the application, but my money is on mutable strings
built on top of an immutable buffer. That's based on looking at my
own string-based Perl code, a lot of which i
At 7:51 PM -0700 4/20/02, Chip Salzenberg wrote:
>I realize that obscure.ops isn't a big deal, but why not make
>it work? Thus this patch. This patch eliminates the versions
>of the ops that accept integers, under the assumption that trig
>on integers is extraordinarily silly.
Applied, thanks.
At 4:54 PM -0400 4/23/02, Mike Lambert wrote:
>This should hopefully fix a problem Clint noticed with his LOAD bug,
>assuming he is using this op. The code was assuming that a string_make's
>passed len==buflen, which is no longer the case.
Applied, thanks. (BTW, could you use either -p or -u for
This should hopefully fix a problem Clint noticed with his LOAD bug,
assuming he is using this op. The code was assuming that a string_make's
passed len==buflen, which is no longer the case.
Mike Lambert
Index: core.ops
===
RCS file
At 3:55 PM -0400 4/23/02, Simon Glover wrote:
>On Tue, 23 Apr 2002, Dan Sugalski wrote:
>
>> At 12:25 PM +0200 4/19/02, Peter Gibbs wrote:
>> >Mike Lambert wrote:
>>
>> >This effect is exacerbated by the fact that "set S1, S2" does a
>> >string_copy - I am still not sure what is supposed to ha
Dan Sugalski:
# Okay folks, time to hash this out once and for all.
#
# Should strings in parrot be mutable or immutable? Right now we've a
# mix, and that's untenable.
Three questions:
1. Which'll be faster?
2. Which'll be simpler?
3. Which is more important?
--Brent Dax <[EMAIL PROTECTED]>
Okay folks, time to hash this out once and for all.
Should strings in parrot be mutable or immutable? Right now we've a
mix, and that's untenable.
--
Dan
--"it's like this"---
Dan Sugalski
On Tue, 2002-04-23 at 12:48, Larry Wall wrote:
> Brent Dax writes:
> : # \talso
> : # \nalso or (latter matching
> : logical newline)
> : # \ralso
> : # \falso
> : # \aalso
On Tue, 23 Apr 2002, Dan Sugalski wrote:
> At 12:25 PM +0200 4/19/02, Peter Gibbs wrote:
> >Mike Lambert wrote:
>
> >This effect is exacerbated by the fact that "set S1, S2" does a
> >string_copy - I am still not sure what is supposed to happen here; I believe
> >that the pure set opcode should
At 1:10 PM -0700 4/19/02, Steve Fink wrote:
>This one got dropped too, and maybe this isn't the right place for
>this anymore.
Applied. Sorry for the wait.
--
Dan
--"it's like this"---
Dan Sugalski
At 7:42 PM +0200 4/19/02, Marco Baringer wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>> Ah, this is incorrect. goto ADDRESS should go to an absolute address,
>> period. It's for use in those times when you *have* an absolute
>> address--for example when you've just fetched the address of
At 6:19 PM +0100 4/19/02, Alberto Manuel Brandão Simões wrote:
>But, this e-mail is not to say this, but to request some kind of help.
>I'm used to check-out, compile and test parrot, looked at the language
>(well, a long time ago) and I'm needing to look to it again. The
>question is, what docume
At 12:25 PM +0200 4/19/02, Peter Gibbs wrote:
>Mike Lambert wrote:
>> Undoing the patch in resources.c seems to fix the problem.
>>
>> Changing:
>> ((Buffer *)buffer)->buflen = req_size;
>> to:
>> ((Buffer *)buffer)->buflen = size;
>> makes it work again.
>
>Just for interest, the pr
Brent Dax writes:
: Sorry to reply to the same message twice, but I just noticed something.
:
: Larry Wall:
: # {n,m}
:
: Isn't that the only use of angle brackets as a quantifier? That's going
: to make parsing more difficult...
How so? It's just a one-character lookahead to s
Oops, forgot to change the subject line. No patch. Patch already
committed.
At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
>At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
>>Precedence is set with the "like' property:
>>
>> my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
>> sub operator:also ($a,$b) is like("and") is inline { $a and $b }
>
>OK, b
Buddha Buck writes:
: At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
: >Precedence is set with the "like' property:
: >
: > my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
: > sub operator:also ($a,$b) is like("and") is inline { $a and $b }
:
: OK, but that limits you
On Mon, Apr 22, 2002 at 05:40:09PM +0100, Piers Cawley wrote:
> Does anyone have an idea of when we're going to see these? Or hashes
> of PMCs, I don't really care which...
Well, we don't have hashes of anything. We already have arrays of
PMCs. You just can't get the PMCs out, only their integer
At 01:12 PM 04-23-2002 -0400, [EMAIL PROTECTED] wrote:
>24 levels of precedence should be enough, else you can always resort to
>parens.
I would have agreed, except that I would have also said that the 14
precedence levels of C should be enough as well -- yet we seem to have
discovered uses f
Me writes:
: > /pat/i m:i/pat/ or // or even m ???
:
: Why lose the modifier-following-final-delimiter
: syntax? Is this to avoid a parsing issue, or
: because it's linguistically odd to have a modifier
: at the end?
Haven't decided for sure to lose it, but it does have several problems.
Fir
In reply to Buddha Buck <[EMAIL PROTECTED]>:
> At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
> >Precedence is set with the "like' property:
> >
> > my sub operator:now ($a,$b) is like("but") is inline { $a but $b
> }
> > sub operator:also ($a,$b) is like("and") is inline { $a and $b }
>
Sorry to reply to the same message twice, but I just noticed something.
Larry Wall:
# {n,m}
Isn't that the only use of angle brackets as a quantifier? That's going
to make parsing more difficult...
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen C
Aaron Sherman writes:
: On Mon, 2002-04-22 at 21:53, Larry Wall wrote:
:
: > * Parens always capture.
: > * Braces are always closures.
: > * Square brackets are always character classes.
: > * Angle brackets are always metasyntax (along with backslash).
: >
: > So a first whack
Brent Dax writes:
: # ?pat? // or even m ???
:
: Whoa, those are moving to the front?!?
The problem with options in general is that they can't easily modify
parsing if they come in back. Now in the particular case of /f and /i,
it probably doesn't matter. But I was trying
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
>Precedence is set with the "like' property:
>
> my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
> sub operator:also ($a,$b) is like("and") is inline { $a and $b }
OK, but that limits you to the, um, 24 standard levels of
Aaron Sherman writes:
: On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
:
: > Perl 6 will try to avoid synonyms but make it easy to declare them. At
: > worst it would be something like:
: >
: > my sub operator:now ($a,$b) is inline { $a but $b }
:
: I see your point, and it makes sense, bu
On Tue, 2002-04-23 at 04:32, Ariel Scolnicov wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > /pat/x /pat/
>
> How do I do a "no /x"? I know that commented /x'ed regexps are easier
> reading (I even write them myself, I swear I do!), but having to
> escape whitespac
On Wed, 24 Apr 2002, Iain Truskett wrote:
> * Larry Wall ([EMAIL PROTECTED]) [23 Apr 2002 11:56]:
>
> [...]
> > * Parens always capture.
>
> Maybe I missed something in the rest of the details, but is anything
> going to replace non-capturing parens? It's just that I do find them
> quite us
* Larry Wall ([EMAIL PROTECTED]) [23 Apr 2002 11:56]:
[...]
> * Parens always capture.
Maybe I missed something in the rest of the details, but is anything
going to replace non-capturing parens? It's just that I do find them
quite useful.
--
iain.
> # =~ $re =~ /<$re>/ ouch?
>
> I don't see the win.
Naturally =~ $re is a bit cleaner, but we can't do that because =~ is
smart match, not regex match.
> # (?=...)
> # (?!...)
> # (?<=...)
> # (?
>
> Cute. (Wait a minute, are
On Mon, 2002-04-22 at 21:53, Larry Wall wrote:
> * Parens always capture.
> * Braces are always closures.
> * Square brackets are always character classes.
> * Angle brackets are always metasyntax (along with backslash).
>
> So a first whack at the differences might be:
[...]
>
On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
> Perl 6 will try to avoid synonyms but make it easy to declare them. At
> worst it would be something like:
>
> my sub operator:now ($a,$b) is inline { $a but $b }
I see your point, and it makes sense, but how will precedence work? What
would
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single
Larry Wall <[EMAIL PROTECTED]> writes:
[...]
> /pat/x/pat/
How do I do a "no /x"? I know that commented /x'ed regexps are easier
reading (I even write them myself, I swear I do!), but having to
escape whitespace is often very annoying. Will I really have to
escape all spaces (
Piers Cawley:
# "Brent Dax" <[EMAIL PROTECTED]> writes:
# > Larry Wall:
# > That's...odd. Is $$ (the variable) going away?
# >
# > # /./s // or /<.>/ ???
# >
# > I think that . is too common a metacharacter to be
# relegated to this.
#
# I think you failed to notice that '/
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Larry Wall:
> That's...odd. Is $$ (the variable) going away?
>
> # /./s// or /<.>/ ???
>
> I think that . is too common a metacharacter to be relegated to
> this.
I think you failed to notice that '/s' on the regex. In general . w
Larry Wall <[EMAIL PROTECTED]> writes:
> /^pat$/m /^^pat$$/
$$ is no longer the current PID? Or will we have to call that '${$}'
in a regex?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
Does anyone have an idea of when we're going to see these? Or hashes
of PMCs, I don't really care which...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
47 matches
Mail list logo
