On Mon, 28 Aug 2000 14:22:03 +1100 (EST), Damian Conway wrote:
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's division. If you
were expecting an expression, it's a regex. Ain't it?
Yes. And that's what makes
By the way, for all you thesis writers and thesis advisors out there -- I
suspect that a separate implementation of the Perl6 lexer and/or Perl6
parser might make a dandy thesis topic...
By the way, this message makes more sense if you s/a separate/an
independent/... :(
Just to extend this idea, at least for the exercise of it, consider:
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
subst; # like s///, pretty
"Randy J. Ray" wrote:
# These are pretty cool...
foreach (@old) { @new = subst /hello/X/gi, @old;
s/hello/X/gi;
push @new, $_;
}
This implies that the subst keyword would *both* modify LIST in-place and
return a complete copy of the list as a
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's
On Fri, 25 Aug 2000 20:44:32 -0400, John Porter wrote:
Nathan Wiger wrote:
I do think
it's worth considering if we're dead-set on losing =~.
But are we?
I hope not. I *like* the =~ syntax, and I would hope we could extend it
to more functions that change one of their parameters, like
Nathan Wiger [EMAIL PROTECTED] wrote:
[...]
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
subst; # like s///, pretty useless :-)
subst /pat/new/;
On Fri, 25 Aug 2000 07:47:14 -0400, Stephen P. Potter wrote:
| Do we have an RFC yet that proposes Perl to be easier parsable?
Great idea. I'd love to see us come up with some "meta" RFCs which say
what the main goals of perl6 are. Then we could align the current RFCs
with those meta RFCs to
At 14.17 +0200 2000-08-25, Bart Lateur wrote:
I propose that one of the main goals should be that perl6 ought to be
bugfree.
Feasable? Nah...
How about "easier to introduce new features into without introducing
new bugs" :-)
Cajo
---
Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236
Adverb
Is it accurate to say that the list of things that would have to be
addressed is table 3-3 on p. 97 of Camel III (unlabelled table on p. 84 of
Camel II)?
Well, mostly. (Note that FH for readline(FH) also is *.c) for
glob('*.c')). I suppose we could forbid pick-your-own-quotes.
But remember
I've RFCed making m mandatory on matches, which would remove some
of the current tokenizing confusion. I'm open to others.
Doesn't seem to be worth it -- there's so much history of
the mass convenience in Perl of being able to write
if (/foo/) { }
or
print if /foo/ /bar/
Tom Christiansen wrote:
print if /foo/ /bar/
Making things harder on users ...
Oh, puhlease; now you're telling us that requiring the user to
write instead
print if m/foo/ m/bar/
is "harder"? Come on; this is perl; if we tell 'em this is the way
it has to be done, and they do
Tom Christiansen writes:
If the goal is to make Perl parsable by emacs, might as well just
say that.
That's not my goal.
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
Being able to have any
Nathan Wiger wrote:
I do think
it's worth considering if we're dead-set on losing =~.
But are we? Have you looked at RFC139? I hope the niceities of it
for the perl programmer are more or less apparent.
--
John Porter
We're building the house of the future together.
Nathan Torkington [EMAIL PROTECTED] writes:
Read my lips: GOOD THING.
Do we have an RFC yet that proposes Perl to be easier parsable?
Damian?
-- Johan
[cc'ed to -regex b/c this is related to RFC 138]
Proposed replacements for m// and s///:
match /pattern/flags, $string
subst /pattern/newpattern/flags, $string
The more I look at that, the more I like it. Very consistent with split
and join. You can now potentially match on
At 11:32 AM 8/25/00 +0200, Johan Vromans wrote:
Nathan Torkington [EMAIL PROTECTED] writes:
Read my lips: GOOD THING.
Do we have an RFC yet that proposes Perl to be easier parsable?
We have one proposing nearly the opposite: RFC 28.
--
Peter Scott
Pacific Systems Design Technologies
Stephen P. Potter writes:
Great idea. I'd love to see us come up with some "meta" RFCs which say
what the main goals of perl6 are. Then we could align the current RFCs
with those meta RFCs to make sure we're meeting those goals.
Highly unlikely to happen, as we have lots of people with
Today around 5:50pm, Tom Christiansen hammered out this masterpiece:
: I've thought about it, and I believe that if were are going to require
: that the function be named every time, that is, via:
:
: m//
:
: that you should then just dispense with the slashes and make it a
: proper
Bart Lateur writes:
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's division. If you
were expecting an expression, it's a regex. Ain't it?
We're talking tokenizing vs parsing. If I'm just getting back a
sequence of
You could "kinda" make it look like a "real" function, as has occasionally
been suggested:
match(STRING, PATTERN, FLAGS)
But before that gets too much support, that has several problems.
First, unless you have rather clever new context coercion prototypes
of type regex (which would
I've thought about it, and I believe that if were are going to require
that the function be named every time, that is, via:
m//
that you should then just dispense with the slashes and make it a
proper function call:
m()
But then you'll find that "m" is a lame name for a
On Fri, 25 Aug 2000 11:17:19 -0600 (MDT), Nathan Torkington wrote:
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an
Bart Lateur writes:
Oh. I would have put my hopes on a better (= more generic) O::Deparse
mechanism to make Perl analyse the source code for you. Rewriting a Perl
in a module seems a bit silly to me.
I don't know enough swear words to say how much I fucking hate the
stupid braindead dumbfuck
24 matches
Mail list logo
