Dan Sugalski wrote:
> I expect we'd want to have some sort of heavy-duty regex optimizer, then,
> to detect common prefixes and subexpressions and suchlike things, otherwise
> we end up with a rather monstrous alternation sequence...
We need a regex merge function too -- then we could write macro
Randal L. Schwartz writes:
> Joe> thing in Perl, we'd need to be able to match a substring, and
> Joe> then call an arbitrary function in the middle of a pattern match,
> Joe> and to back out the call if the match failed.
>
> Already done in 5.6. :) "perldoc perlre".
Anyone who has actually tri
Randal L. Schwartz writes:
: > "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes:
:
: Joe> This is done by using SNOBOL's dynamic function evaluation and
: Joe> conditional assignment during a pattern match. To do this kind of
: Joe> thing in Perl, we'd need to be able to match a substring, and
> "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes:
Joe> This is done by using SNOBOL's dynamic function evaluation and
Joe> conditional assignment during a pattern match. To do this kind of
Joe> thing in Perl, we'd need to be able to match a substring, and
Joe> then call an arbitrary function
> I was wondering this morning whether we ought to write the Perl 6
> parser as a set of recursive regexes. Might make it easier to plug in
> new productions on the fly. And designing the parser around regexes
> might indicate ways in which Perl's regexes are not yet powerful
> enough.
>
There'
> I was wondering this morning whether we ought to write the Perl 6
> parser as a set of recursive regexes.
That would also solve one of my nagging headaches:
RFC XXX: Parse::RecDescent 2.0 *is* Perl 6.0
Of course, then we'd have to have Perl 6 out "by Christmas"!
;-)
Damian
P
At 11:18 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
>: >However, for Perl 6 I'd really like to see run-time access to the
>: >Real Tokenizer (tm):
>: >
>: > use tokenizer;
>: >
>: > my $tree = tokenizer( $sourcecode
Larry Wall wrote:
>
> Dan Sugalski writes:
> : At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
> : >However, for Perl 6 I'd really like to see run-time access to the
> : >Real Tokenizer (tm):
> : >
> : > use tokenizer;
> : >
> : > my $tree = tokenizer( $sourcecode );
> : >
> : >Th
Dan Sugalski writes:
: At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
: >However, for Perl 6 I'd really like to see run-time access to the
: >Real Tokenizer (tm):
: >
: > use tokenizer;
: >
: > my $tree = tokenizer( $sourcecode );
: >
: >This would be dead handy for building sourc
At 10:35 AM 8/19/00 +1000, Damian Conway wrote:
>However, for Perl 6 I'd really like to see run-time access to the
>Real Tokenizer (tm):
>
> use tokenizer;
>
> my $tree = tokenizer( $sourcecode );
>
>This would be dead handy for building source-code filtering modules,
>rather than
David L. Nicol wrote:
>
> RFC: It's all exception handling. I imagine the core syntax description
> as a set of catch clauses. Every token generates a "TOKEN-$whatever"
> exception, which is caught according to the current situation. How's
> that for a general paradigm? These things can be o
"Bryan C. Warnock" wrote:
>
> On Fri, 18 Aug 2000, David L. Nicol wrote:
> > There will Be No Perl7
>
> Of course not. Odd numbers are the development releases. The next
> Perl after 6 will be 8.
So maybe the reference implementation should be written in perl 4. Did
perl 4 have references?
On Fri, Aug 18, 2000 at 05:22:17PM -0500, David L. Nicol wrote:
>RFC: Perl6 is Final. There will Be No Perl7
>RFC: Everything is Accessible and Mutable
>RFC: The perl6 reference implementation, no matter how slow it is,
>will be written in perl5, in some kind of well defined virtual machine.
>
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > RFC: Perl6 is Final. There will Be No Perl7
> >
> > We declare that our framework willbe so flexiblke
> > that anything can be done with it and there will be no penalty
> > for something being in-core opposed to out-of-core and so on
Nathan Wiger writes:
> Anyone RFC'ing this yet?
I could RFC it in vague terms, but I'm waiting to see how things
like interfaces turn out.
> Which reminds, anyone gonna RFC the rumored death of typeglobs? :-)
I figured that as Larry had used it as an example of things that were
up for grabs in
Nathan Torkington wrote:
>
> Exporter is pure Perl, but
> I'd love to see its functionality moved into the core (or, indeed,
> replaced by a general compile-time interface setup with separate
> runtime execution semantics) for speed reasons.
Anyone RFC'ing this yet?
This time I'm *not* voluntee
Jeremy Howard wrote:
>
> > Steve Fink writes:
> > > And both those examples apply to the underpinnings. Ok, maybe I have an
> > > unusually broad definition of the word "underpinnings". Think "anything
> > > that can't be done with a pure perl module".
> >
> Say "anything that can't be done *fast
> : Text::Balanced has to track in order to parse almost any Perl code.
>
> It's a good thing you said "almost".
Ah, that Jesuit education finally pays off! ;-)
> Does it parse [*]] correctly?
No, but only because C ignores punctuation vars entirely.
It would be a simple fix to
[EMAIL PROTECTED] writes:
: Bare C and bare C *are* the main culprits. They require
: the tokenizer to track expression semantics so that when it encounters a
: '/' or '?' it can tell whether a pattern is plausible in this place or
: whether they've reached a division or hook operator, respectivel
> > * The match operator, C, is always required (bare C
> > becomes a fatal error).
>
> I could live with that. Damian's done some work trying to tokenize
> Perl and knows what the weird edge cases are. Damian, can you post
> your short list?
Bare C and bare C *are* the main
> Steve Fink writes:
> > And both those examples apply to the underpinnings. Ok, maybe I have an
> > unusually broad definition of the word "underpinnings". Think "anything
> > that can't be done with a pure perl module".
>
Say "anything that can't be done *fast*enough* with a pure perl module" an
On Fri, 18 Aug 2000, David L. Nicol wrote:
> There will Be No Perl7
Of course not. Odd numbers are the development releases. The next
Perl after 6 will be 8.
Seriously, while a worthwhile goal, this is rather short-sighted.
The industry and the world will continue to change in spite (or
beca
Stephen P. Potter writes:
> * The match operator, C, is always required (bare C becomes a fatal
> error).
I could live with that. Damian's done some work trying to tokenize
Perl and knows what the weird edge cases are. Damian, can you post
your short list?
> * Replace C, C, and C with equiva
Steve Fink writes:
> And both those examples apply to the underpinnings. Ok, maybe I have an
> unusually broad definition of the word "underpinnings". Think "anything
> that can't be done with a pure perl module".
I'm not wild about that metric, either. Exporter is pure Perl, but
I'd love to see
David L. Nicol writes:
> RFC: Perl6 is Final. There will Be No Perl7
>
> We declare that our framework willbe so flexiblke
> that anything can be done with it and there will be no penalty
> for something being in-core opposed to out-of-core and so on.
Bad idea. You can't make anything
Here's my RFC todo list which I am dropping like a good mensch
on the occasion of Friday Evening.
RFC: Perl6 is Final. There will Be No Perl7
We declare that our framework willbe so flexiblke
that anything can be done with it and there will be no penalty
for something being in-
Nathan Torkington wrote:
>
> Steve Fink writes:
> > We are NOT here to construct a radically better language. We are here to
> > design the underpinnings of one.
>
> Perhaps. And by "perhaps", I mean "no".
>
> We're here to say what we'd like to see in the next version of Perl.
> These can be
Nathan Torkington writes:
: Steve Fink writes:
: > We are NOT here to construct a radically better language. We are here to
: > design the underpinnings of one.
:
: Perhaps. And by "perhaps", I mean "no".
:
: We're here to say what we'd like to see in the next version of Perl.
: These can be bi
Steve Fink writes:
> We are NOT here to construct a radically better language. We are here to
> design the underpinnings of one.
Perhaps. And by "perhaps", I mean "no".
We're here to say what we'd like to see in the next version of Perl.
These can be big things (currying) or small (hashes retur
Decklin Foster wrote:
>
> [replying from here since this is the only way I received it]
>
> > "Myers, Dirk" wrote:
> > >
> > > $line/pattern/ ;
> >
> > > /pattern/ ($line) ;
>
> I don't think these should be changed. Here's how I tend to pronouce
> things:
>
> $x = 'foo'; #
Nathan Wiger wrote:
>
> We're getting deluged with RFC's and emails. We should start thinking
> "will this RFC or idea *add value* to Perl 6?". If not, and it just
> makes something work differently, it _might_ not be worth an RFC.
I disagree completely. For one thing, there's no such thing as P
[replying from here since this is the only way I received it]
> "Myers, Dirk" wrote:
> >
> > $line/pattern/ ;
>
> > /pattern/ ($line) ;
I don't think these should be changed. Here's how I tend to pronouce
things:
$x = 'foo'; # "x gets foo"
/bar/;# "match on bar"
> I certainly don't want m, tr, or s to go away
> (or /regex/ either.) But the =~ bothers me.
I don't think we should change everything. There's a big risk that we
get "fix-happy" and change stuff that doesn't really make an
improvement. Personally, I like =~ because it has a nice analogy to the
(I'm assuming you intended this for perl6-language)
"Myers, Dirk" wrote:
>
> > I certainly don't want m,
> > tr, or s to go away (or /regex/ either.) But the =~ bothers me. How
> > about disallowing m{...} and using m{expr}/.../?
>
> How about this, for the really compact way to do it:
>
>
"Stephen P. Potter" <[EMAIL PROTECTED]> writes:
> * Socket functions (such as C, C, etc) should be moved from
> the core to modules/libraries.
> * Math functions (such as C, C, C, etc) should be moved
> from the core to modules/libraries.
> * IPC functions (such as C, C, C, etc) should be
>
> On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote:
> > * Replace C, C, and C with equivalent regularized
> > functions that take mulitple arguments instead of using specialized
> > syntax. It would be best if the names could be more "complete", like
> > match(), translate(
> "SPP" == Stephen P Potter <[EMAIL PROTECTED]> writes:
SPP> * The match operator, C, is always required (bare C
SPP> becomes a fatal error).
maybe
SPP> * Replace C with flag to C, and remove special meaning
SPP> of C.
yes
SPP> * Socket functions (such as C, C, etc) should be mo
On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote:
> * Replace C, C, and C with equivalent regularized
> functions that take mulitple arguments instead of using specialized
> syntax. It would be best if the names could be more "complete", like
> match(), translate(), and sub
* Stephen P. Potter ([EMAIL PROTECTED]) [18 Aug 2000 03:06]:
> I don't see these ideas in RFCs:
[Reordered a bit and some items removed]
> * Socket (such as C, C, etc)
> * Math (such as C, C, C, etc)
> * IPC (such as C, C, C, etc)
> * "User" (C, , C, C)
> * Group (C, C, C)
> * Network (C, C, C,
39 matches
Mail list logo
