On Mon, 28 Aug 2000 20:26:41 -0700, Nathan Wiger wrote:
foreach (@str) { print "Got it" if match /\w+/, @str;
if (/\w+/) { $gotit = 1 };
}
print "Got it" if $gotit;
Now if DWIM just worked for email as well... ;-)
You mean, like grep?
print "Got it" if
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
Do we have an RFC yet that proposes Perl to be easier parsable?
Damian?
Working on it.
Damian
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
[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
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
Lightning flashed, thunder crashed and [EMAIL PROTECTED] (Johan Vromans) whi
spered:
| Do we have an RFC yet that proposes Perl to be easier parsable?
| Damian?
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
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
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
At 10:57 AM 8/25/00 -0600, Tom Christiansen wrote:
If your primary goal is trivial parsing, there's a *LOT* of other
stuff you have to change. For example, no more pick your own quotes.
And you can't have an angle operator, since it could be a less-than,
nor can you have here docs, which might
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
Tom Christiansen writes:
There are unsolvable problems here, though.
Unsolvable without knowledge of the Perl language, yes. As
always, easy tasks will be easy and there'll be a continuum of
difficulty as the task gets harder.
I just want easy filters to be possible!
Nat
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:
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
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
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
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
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.
[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
On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote:
Damian Conway's Text::Balanced module does a pretty good job of
tokenizing Perl code. However, bare C/.../ and C?...? require
semantic analyis to distinguish them from division and the hook
(CA?B:C) operator.
To remove this hassle, and
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Require explicit m on matches, even with ?? and // as delimiters.
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: August 20, 2000
Last Modified: August 24, 2000
Version: 2
27 matches
Mail list logo
