Hi Dave, I'm not currently subscribed to the p6 lists but noticed your
guidelines while browsing.
I'd like to see some more 'should's in the layout section; in particular:
- binary operators should have a space on either side;
- parentheses should not have space immediately after the opening pare
> Well, other languages have explored that option, and I think that makes
> for an unnatural interface. If you think of regexes as part of a
> larger language, you really want them to be as incestuous as possible,
These days we can be that without feeling that guilty since pcre exists.
> just a
On Monday 04 June 2001 08:38 pm, Jarkko Hietaniemi wrote:
> > : Though whether being able to
> > : yank out the RE engine and treat it as a standalone library is
> > : important enough to warrant being treated as a design goal or not is a
> > : separate issue. (I think so, as it also means I can t
Jarkko Hietaniemi writes:
: > : Though whether being able to
: > : yank out the RE engine and treat it as a standalone library is important
: > : enough to warrant being treated as a design goal or not is a separate
: > : issue. (I think so, as it also means I can treat it as a black box for th
Dan Sugalski writes:
: Yeah, a lot of that's definitely a problem, as is the manipulation of the
: return stack and some assignment bits. (You can cut the time split takes in
: half by having the destination array presized, for example)
That's why the current version Perl goes to a great deal o
> : Though whether being able to
> : yank out the RE engine and treat it as a standalone library is important
> : enough to warrant being treated as a design goal or not is a separate
> : issue. (I think so, as it also means I can treat it as a black box for the
> : moment so there's less to t
Dan Sugalski writes:
: At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
: >Dan Sugalski writes:
: >: Are you speaking of the nodes in regnode.h? I hadn't considered them as
: >: regular perl opcodes--I figured they'd stay internal to the regex engine so
: >: we could keep it reasonably modular.
: >
:
At 01:09 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>In my experience, perl opcodes have not been the performance bottleneck
>in perl5.
>
>It seems it isn't actually the loop that's the bottleneck in perl5. I
>profiled a whole bunch of different perl programs, using a lot of
>different versions o
At 11:46 AM 6/1/2001 -0700, [EMAIL PROTECTED] wrote:
>On Tue, May 29, 2001 at 06:20:40PM -0400, Dan Sugalski wrote:
> >
> > I really think we'll win if we have support for at least integers as well
> > as PMCs. There's potentially a lot of integer work that'll be generated by
> > the optimizer and
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> No, not really. The big reasons I wasn't planning on unification are:
DS> *) It makes the amount of mental space the core interpreter takes
DS> up smaller
not if the regex ops were developed separately. all it will do is expand
th
Jarkko Hietaniemi wrote:
> Err...a regex that isn't a regex, is this a Zen koan...? Ahhh, you
> want to emulate the state machine in Pure Perl. Okay... next thing
> you want to do is to write symbolic assembler in C...? :-)
I have my reasons :)
Actually, I want to write a c into perl compile
At 03:08 PM 6/4/2001 -0500, Jarkko Hietaniemi wrote:
>On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> > At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
> > >On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > > > Does anyone have on-their-shelves a regex-into-non-re
At 04:20 PM 6/4/2001 -0400, Uri Guttman wrote:
>then regexes can be also debugged in detail with the perl debugger.
>that assumes the debugger has access to single stepping ops which is an
>intriguing idea. BTW this is the kind of feature that dan wanted the
>debugger PDD to have. having this feat
At 11:24 AM 6/4/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Are you speaking of the nodes in regnode.h? I hadn't considered them as
>: regular perl opcodes--I figured they'd stay internal to the regex engine so
>: we could keep it reasonably modular.
>
>I don't think that's a terribly s
On Mon, Jun 04, 2001 at 04:20:12PM -0400, Uri Guttman wrote:
> that doesn't address larry's point which is very important.
No, I was replying to David, so I thought I'd address his point instead.
Conventional, I know. :)
> the regex compiler needs to be able to generate the equvilent of the
> a
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> OK, here's how you do it. Run perl -Mre=debug -e '/your regexp/',
SC> and use Perl to parse the bit in the middle. That's a state machine,
SC> so we can emulate it with subroutines.
SC> So, for instance: perl -Mre=debug -e '/fo+b
On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
> >On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > > Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
> >
> >Does anyone have on-their-shelve
On Mon, Jun 04, 2001 at 03:43:43PM -0400, Dan Sugalski wrote:
> I think he's looking for something that turns a regex into perl that
> doesn't involve regexes.
Oh, well, if we follow Larry's suggestion and have regexp matching ops,
then we could claim that the regex *is* Perl, it's just written
At 08:34 PM 6/4/2001 +0100, Simon Cozens wrote:
>On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> > Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
>
>Does anyone have on-their-shelves a David-Nicol-into-English translator? :)
I think he's looking for so
On Mon, Jun 04, 2001 at 02:26:26PM -0500, David L. Nicol wrote:
> Does anyone have on-their-shelves a regex-into-non-regex-perl translator?
Does anyone have on-their-shelves a David-Nicol-into-English translator? :)
> run time is not an issue
Wrong.
--
I decided to spread the bad mood: Dress
Larry Wall wrote:
> "Sure, you can download the object code for this 5 line Perl program
> into your toaster...but you'll also have to download this 5 gigabyte
> regex interpreter before it'll run."
>
> That's a scenario I'd love to avoid. And if we can manage to store
> regex opcodes and
> The fact that Perl 5's regex engine is a royal pain to deal with should
> be a warning to us.
>
> Much of the pain of dealing with the regex engine in Perl 5 has to do
> with allocation of opcodes and temporary values in a non-standard
> fashion, and dealing with the resultant non-reentrancy on
Dan Sugalski writes:
: Are you speaking of the nodes in regnode.h? I hadn't considered them as
: regular perl opcodes--I figured they'd stay internal to the regex engine so
: we could keep it reasonably modular.
I don't think that's a terribly strong argument--one could justify any
number of un
23 matches
Mail list logo
