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?
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."
"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
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 '/
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 (
> /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
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
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:
[...]
>
> # =~ $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
* 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.
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
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
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
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
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
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
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
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 }
>
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
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
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
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
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
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
Oops, forgot to change the subject line. No patch. Patch already
committed.
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
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 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 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
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
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
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]>
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
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 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
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.
On Tue, 2002-04-23 at 12:48, Larry Wall wrote:
> Brent Dax writes:
> : # \talso
> : # \nalso or (latter matching
> : logical newline)
> : # \ralso
> : # \falso
> : # \aalso
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
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
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
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
> : 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
> > : 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
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
> 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.*?
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
47 matches
Mail list logo
