> If =~ allowed "indirect object" notation as -> does, then we could write
>
> s $str (pat){rep};
> and
> for ( grok %db /Name/$name/g ) {
Yeah, but I'm not sure what those are supposed to do. They look way too
obscure for me.
As written I don't see an advantage in the RFC. I th
[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 @mul
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.
> 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
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 fu
At 11:55 PM 8/25/00 +, Ed Mills wrote:
>Having just coded some more perl resplendent with this syntax:
>
> $in{pmonth}=$usr{paidon};
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
>
>once again I'll suggest (then I quit)
>
>$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
>
>
>is a LOT nic
Ed Mills wrote:
>
> Having just coded some more perl resplendent with this syntax:
>
> $in{pmonth}=$usr{paidon};
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
>
> once again I'll suggest (then I quit)
>
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
>
> is a LOT nicer, and more Per
Having just coded some more perl resplendent with this syntax:
$in{pmonth}=$usr{paidon};
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
once again I'll suggest (then I quit)
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
is a LOT nicer, and more Perlish (see split) way of doing this. I'
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 functi
David Corbin wrote:
> In addition to the four I posted, originally, I've added two. Here's my
> working list.
>
> native pattern matching;
> list manipulation
> aweswome text processing.
> It's application glue (thanks Tim)
> Ability to write powerful 1-line programs.
> Make easy things easy a
David L. Nicol writes:
> If we use exceptions of some kind to handle
> syntax, encountering an exception of type "unknown-keyword:Cmp" could
> result in the subroutine definition getting run to clarify this piece
> of code.
I'm nervous about this. I'm trying to picture what happens, and
having t
My largely ignored RFC about "shell style redirection" suggested
pretty much this. perl5 has it as a feature hidden on the fourth page
of the perldoc for "open"
It also lets < neatly double as a compact print operator
Chaim Frenkel wrote:
>
> With threading coming, would having a >() and
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 c
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> This is good for comparison but bad for math. Epoch seconds are
NT> good for both. That's why *I* use them. You can continue to use
NT> ISO mumble and have it work for you. I'm not breaking your code.
NT> There's also the issue
Michael G Schwern wrote:
> Compare:
>
> dbmopen(%foo, 'somefile', 0644);
>
> with:
>
%foo:persistent(file=>somefile);
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 ope
hashes and regexes, and the scripting aspect (no explicit, seperate compile
step).
Its not the ONLY language with these aspects, but its the only one I know of
with ALL of them. Also I like the feeling of community and in some respect,
rebellion.
Anyhow those are what distinguish Perl for me.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Split Scalars and Objects/References into Two Types
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Last-Modified: 25 Aug 2000
Version: 2
Mailing List: [EMAIL PR
Last week when I wrote "everything is an exception" this is what
I was talking about.
Nathan Torkington wrote:
> This raises another issue, though:
>
> You'd obviously want to have a module that collected together your
> favourite new operators. But if they were lexically scoped, they'd
>
Jarkko Hietaniemi wrote:
> " e q "
that breaks our long and glorious tradition of splitting tokens
on whitespace. How about e_q for this one?
> That is, an operator that ignores any leading, any trailing, and treats
> all intraspace as equivalent. If the embedded space is confusing,
On Fri 25 Aug, Nathan Wiger wrote:
> > I was sorta going under the assumption that <<< would cause leading and
> > trailing whitespace to be ignored (not stripped) when looking for the
> > end-of-here-doc indicator. Because whitespace is ignored, I was then
> > proposing some new syntax for strip
where it was "Remove
sockets from core"...
Tom Christiansen wrote:
>
> >I would like to see a set of "requirements" that make Perl what it is.
> >I think we all have a vague idea of what makes Perl great, but I'm also
> >sure there's a lot of variation. With a SHORT list of requirements, it
>
Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> Probably has to be added to perl internals...
>
> I wonder what will happen with overloads though - is eq/i a new operator
> to overload or is the case-insensitivity somehow magically done by the
> Perl interpreter even though eq was overl
At 02:06 PM 8/25/00 -0400, Uri Guttman wrote:
>i like that. but is that only platform implementation specific? i see a
>possibility of requesting (via a pragma) an alternative implementation of
>binary (see i used the new term!).
I'd like to get overridable opcode functions and function functions
With threading coming, would having a >() and <() syntax be useful?
So within the >() and <() constructs STDIN and STDOUT (or perhaps only
the default filehandle) would be redirected.
sub proc_arg1 { while(<>) { } }
sub proc_arg2 { while(<>) { } }
while(<>) {
(<{proc_arg1}, <{
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
i cc'ed to language as this issue spans then as well as internals.
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> We're fighting multiple definitions of "core" here. Please distinguish
LW> the core of the language from the core of the implementation--they're
LW> two entirely di
>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 for readline(FH) also is <*.c) for
glob('*.c')). I suppose we could forbid pick-your-own-quotes.
But remember
I'm not sure which is the best mailing list to send this to, so forgive
me if I'm off.
I'll be glad to RFC this if there is interest.
There are several modules I've run across that require you to edit them
after you've installed them. I consider this to be a very bad thing.
What I'm thinking is
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 progr
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 migh
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 th
>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/
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 di
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
Jonathan Scott Duff wrote:
>
> We just need a
> way to overload the binding operator (I didn't see it mentioned in
> a quick skim of overload.pm) so that
>
> THING =~ OTHER_THING
>
> is translated to
>
> bind(THING,OTHER_THING)
>
> with bind() having user-defined semantics.
Not
Please discuss this RFC on the -objects sublist. Thanks.
Matt, you should probably update the Mailist List to
perl6-language-objects for v2.
-Nate
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> OO Integration/M
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO Integration/Migration Path
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 161
=head1 ABSTRACT
Allow Perl 6 to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
OO Integration/Migration Path
=head1 VERSION
Maintainer: Matt Youell <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 161
=head1 ABSTRACT
Allow Perl 6 to
On Thu, Aug 24, 2000 at 10:59:07PM -0700, Peter Scott wrote:
> So what about the possibility of user-defined q[a-z]// (using a letter that
> hadn't already been taken), where you get to specify the actions of =~ and
> probably more operators? Sounds like it has a lot in common with operator
>
[Apologies for the late reply. Still catching up]
On Thu, 17 Aug 2000 20:51:01 -0500, David L. Nicol said:
> What if its a method of anything in an array? $_ is already
> a reference to the object on the array in for loops rather
> than a copy of it. What if we make change be not something a
Peter Scott wrote:
>
> So what about the possibility of user-defined q[a-z]// (using a letter that
> hadn't already been taken), where you get to specify the actions of =~ and
> probably more operators? Sounds like it has a lot in common with operator
> overloading - maybe even just an extens
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
Adv
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
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 curr
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
On Thu, 24 Aug 2000 17:12:11 -0700, Peter Scott wrote:
> eval {
> open "some_name_for_a_file_that_does_not_exist";
> # $! set to "file or directory does not exist"
> undef;
> }
> # $! set to "" (or undef, whichever makes more sense) on
> # eval block terminatio
On Thu, 24 Aug 2000 21:06:30 -0700, Nathan Wiger wrote:
> 1. Ignore leading/trailing whitespace in here string terminators.
> All of these should work:
>
>EOL
> EOL
>EOL # this is the end of the here doc
>
> I don't think a special syntax is needed just for this. Make
> thi
48 matches
Mail list logo
