> > > Dave Storrs wrote:
> > > Can we please have a 'reverse x' modifier that means "treat whitespace as
> > > literals"? Yes, we are living in a Unicode world now and your data could
> > >
> > > /FATAL ERROR\:Process (\d+) received signal\: (\d+)/
> >
> > I don't see how this example is near
Andy Wardley <[EMAIL PROTECTED]> writes:
> On Sat, Jun 08, 2002 at 06:51:19AM +1000, Damian Conway wrote:
>> I have no doubt that, once Perl 6 is available, we'll see a rash of
>> modules released in the Grammar:: namespace. Including
>> Grammar::HTML and Grammar::XML.
>
> I have no doubt that, o
Jonathan Scott Duff wrote:
> > > rule val {
> > > [ # quoted
> > >$b := <['"]>
> > >( [ \\. | . ]*? )
> > >$b
> > > ] | # or not
> > >(\H+)
> > > }
> >
> > Not quite. Assigning to $b is a capture.
>
> I'm confused. The examples in A5 all show $var := (pa
On Fri, 7 Jun 2002, Luke Palmer wrote:
> > Dave Storrs wrote:
> > Can we please have a 'reverse x' modifier that means "treat whitespace as
> > literals"? Yes, we are living in a Unicode world now and your data could
> >
> > /FATAL ERROR\:Process (\d+) received signal\: (\d+)/
>
> I don't
On Mon, 10 Jun 2002, Larry Wall wrote:
> On Mon, 10 Jun 2002, Dave Storrs wrote:
>
> >
> > I assume that 'fatal.pm' is a new pragma.
>
> Already exists for Perl 5, actually.
*blush* Must have missed it. Drat, and I just finished rereading
Camel III. Apologies.
Dave
On Mon, 10 Jun 2002, Dave Storrs wrote:
>
> I assume that 'fatal.pm' is a new pragma.
Already exists for Perl 5, actually.
> 1) What (if anything) does it do, aside from turning 'fail' into a fatal
> exception when used outside a regex?
What fatal currently does is wrap built-ins that might r
I assume that 'fatal.pm' is a new pragma.
1) What (if anything) does it do, aside from turning 'fail' into a fatal
exception when used outside a regex?
2) Do you need to use it before you can (usefully) use 'fail' INSIDE a
regex? (I would assume not, but thought I'd check.)
Dave
On Fri, 7
On Sun, Jun 09, 2002 at 03:34:16PM +1000, Damian Conway wrote:
> Trey Harris wrote:
> > rule val {
> > [ # quoted
> >$b := <['"]>
> >( [ \\. | . ]*? )
> >$b
> > ] | # or not
> >(\H+)
> > }
>
> Not quite. Assigning to $b is a capture.
I'm confused. The e
Damian Conway <[EMAIL PROTECTED]> outlined his plans for world domination:
[...]
>
> Dammit, you fools! Do I have to think of *everything*??? Just tie him to a
> steel bench and apply the Ruby laser!
>
> I do apologize, Mr Wardley. Good evil assistants are just impossible to get
> these days.
Erik Steven Harrison henched:
> Ahhh, duh . . . Docter Claw . . .er Conway, uh, the Python always throws up
> Perl Coders . . . Shoulds we maybe bash him with the Giant Shell, or TCL him
> to death . . .
Dammit, you fools! Do I have to think of *everything*??? Just tie him to a
steel bench and
Trey Harris wrote:
> On second reading, it occurs to me that this wouldn't work quite right,
> because the :w would imply a \s+ between and , between
> the equals, and before the .
No. Under :w you get \s+ between literal sequences that are potential identifiers, and
\s* between anything else.
>
>Ah, Mr Wardley, I see you have finally apprehended the magnitude of my
>nefarious plan. Five years of plotting and scheming, of gaining influence and
>gradually insinuating my dastardly code creations into the community
>consciousness: all
>about to culminate in unleashing of Perl 6 on an uns
In a message dated Sun, 9 Jun 2002, Damian Conway writes:
> Trey Harris wrote:
> > rule parsetag :w {
> > $tagname :=
> > %attrs := [ () =
> > ()
> > ]*
> >/?
> >
> > }
On second reading, it occurs to me that this wouldn't work
At 10:21 PM 6/9/2002 +1000, Damian Conway wrote:
>Richard Nuttall wrote:
> > Grammar::Python, Grammar::Ruby, Grammar::PHP ?
>
>I should imagine that the first two at least would be very likely, given that
>we wish both of those languages to run on top of Parrot.
Given that by the time Parrot is b
Damian Conway:
# Richard Nuttall wrote:
# >
# > > I have no doubt that, once Perl 6 is available, we'll see
# a rash of
# > > modules released in the Grammar:: namespace. Including
# > > Grammar::Romana, Grammar::Klingon, Grammar::Buffy,
# Grammer::Mispelt,
# > > and others... :-)
# >
# > G
Richard Nuttall wrote:
>
> > I have no doubt that, once Perl 6 is available, we'll see a
> > rash of modules released in the Grammar:: namespace.
> > Including Grammar::Romana,
> > Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-)
>
> Grammar::Python, Grammar::Ruby, Grammar::
> I have no doubt that, once Perl 6 is available, we'll see a
> rash of modules released in the Grammar:: namespace.
> Including Grammar::Romana,
> Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-)
Grammar::Python, Grammar::Ruby, Grammar::PHP ?
R.
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::Romana,
> Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-)
Ah, Mr Wardley, I see you have finally apprehended the magnitude of my
nefarious
On Sat, Jun 08, 2002 at 06:51:19AM +1000, Damian Conway wrote:
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
I have no doubt that, once Perl 6 is available, we'll see a rash of module
Trey Harris wrote:
> I guess this is as good an opportunity as any to be sure I've got what's
> going on. So, here's a first, simple, addmitedly broken hack at a simple
> parser for xml-ish start tags and empty entities:
>
> rule lt { \< }
> rule gt { \> }
> rule identifier {
> # I don't kn
Dave Storrs yiked:
> Yikes. Ok, I obviously badly misunderstood that. I'll go back
> and reread it. So, can you provide an example of a "pattern nested
> within a closure", since I obviously didn't understand?
Sure:
m/ if { /? ::: / and print $0.{comment} } /
The C? ::: />
On Fri, 7 Jun 2002, Peschko, Edward wrote:
: Let me get this straight. the grammar of Perl is reprogrammable,
: and expressed in perl6. And a script is parsed using this grammar,
: on the fly, hence portions of scripts could have different grammars
: than other parts.
Where have you been for the
On 6/7/02 5:44 PM, Damian Conway wrote:
> John Siracusa wrote:
>>> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
>>> released in the Grammar:: namespace. Including Grammar::HTML and
>>> Grammar::XML.
>>
>> Why not just make Grammar::DTD, and then make Grammar::Genera
f
On Fri, Jun 07, 2002 at 05:10:49PM -0400, Trey Harris wrote:
> In a message dated Fri, 7 Jun 2002, [EMAIL PROTECTED] writes:
> > The most serious objection to this was 'well, use modules for matching *ml" -
> > which simply points out that the current incarnation of perl6 regex doesn'
> > t han
John Siracusa wrote:
> > I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> > released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
>
> Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
> Then use those to make all the
On Fri, 7 Jun 2002, John Siracusa wrote:
> On 6/7/02 4:48 PM, Luke Palmer wrote:
> > rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
> >
> > Then, you can match an img tag with:
> >
> > / /
> >
> > See, isn't that great?
>
> Don't you mean, "see, isn't that massively over-simplifie
On 6/7/02 4:51 PM, Damian Conway wrote:
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
Then use those to make
On 6/7/02 4:48 PM, Luke Palmer wrote:
> rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
>
> Then, you can match an img tag with:
>
> / /
>
> See, isn't that great?
Don't you mean, "see, isn't that massively over-simplified?" ;)
(but yeah, we get the idea... :)
-John
In a message dated Fri, 7 Jun 2002, [EMAIL PROTECTED] writes:
> The most serious objection to this was 'well, use modules for matching *ml" -
> which simply points out that the current incarnation of perl6 regex doesn'
> t handle a very large class of matching problems very well.
I don't think th
> The most serious objection to this was 'well, use modules for matching *ml" -
> which simply points out that the current incarnation of perl6 regex doesn'
> t handle a very large class of matching problems very well.
The modules use regexes. They just spend more time on them and make them
bet
>> Can we please have a 'reverse x' modifier that means "treat whitespace as
>> literals"?
> I'll talk about that with Larry. If he were to approve it, it might possibly
> be :W.
Likewise, could we please have a modifier that makes <> literal, and aliases
<> as something else so *ml can match ea
On Fri, 7 Jun 2002, Dave Storrs wrote:
> Just to be sure I understood: you meant that (A) yes, you can use
> fail in a subroutine outside a regex, and (B) if you do, it is no
> different from die. Is that correct?
Depends on the caller's use of "use fatal". If they don't use fatal,
it re
On Fri, 7 Jun 2002, Damian Conway wrote:
> Dave Storrs wrote:
>
> > Somehow, this feels like we're trying to roll all of Prolog
> > into Perl,
>
> No. We're rolling in all of yacc/lex/RecDescent instead. ;-)
And this should reassure me _why_? *grin*
> > Just to verify, this:
> >
> >
On Fri, 7 Jun 2002, David Wheeler wrote:
> I was hoping for a magic array that would hold
> the actual *matches*, rather than pointers to their character positions.
A5 says that @$0 is that array.
Larry
On 6/7/02 11:21 AM, "David Wheeler" <[EMAIL PROTECTED]> claimed:
> Not to mention kinda useless. I was hoping for a magic array that would hold
> the actual *matches*, rather than pointers to their character positions.
And it appears to be C<@$0>. Duh. Sorry for the noise, folks.
David
--
Dav
On 6/7/02 10:12 AM, "Jonathan E. Paton" <[EMAIL PROTECTED]> claimed:
> A5, under "RFC 072: Variable-length lookbehind":
>
> "Did I mention that the magical @+ and @- arrays are gonna be real dead?
>Never could remember which one was which anyway..."
Not to mention kinda useless. I was hop
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On 6/6/02 11:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>
> >> / $2:=(.*?), \h* $1:=(.*) /
> >>
> >> Does this imply that $1, $2, etc are now read-write outside of regexen?
> >
> > No.
>
> Maybe this is a RTFM question, but does
On 6/6/02 11:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>> / $2:=(.*?), \h* $1:=(.*) /
>>
>> Does this imply that $1, $2, etc are now read-write outside of regexen?
>
> No.
Maybe this is a RTFM question, but does Perl 6 (or Perl 5, for that matter)
have some magical array that
Note: My answers are non-authoritative. Don't trust me.
> Can we please have a 'reverse x' modifier that means "treat whitespace as
> literals"? Yes, we are living in a Unicode world now and your data could
> theoretically be coming in from a different character set than expected.
> But there
At 10:59 PM -0700 6/6/02, Dave Storrs wrote:
>Page 8:
>
>The u1-u3 mods all say "level 1 support". I assume this was a typo, and
>they should go (u1 => 'level 1', u2 => 'level 2', u3 => 'level 3').
Yeah. I'd avoid these if you can manage. There's not a whole lot of
reason to mandate Unicode in
Dave Storrs wrote:
> I admit I'm a bit nervous about that...so far, I'm completely sold on
> (basically) all the new features and changes in Perl 6, and I'm eagerly
> anticipating working with them. But this level of change...I don't know.
> I've spent a lot of time getting to be (reasonaly) goo
41 matches
Mail list logo