On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > This RFC proposes two-stage autoloading: one stage may be registered
> > to act when the symbol is encountered at compile time, the other
> > when the subroutine is called. Autoloading on the seco
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > proposes a convenient syntax to slice multi-dimensional arrays;
> It is hard to evaluate this proposal without more context. In particular:
>
> - How does it relate to RFC 204? Is it an alternative, or an addition?
204 cannot b
=head1 VERSION
Maintainer: Michael Schwern <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: perl6-language
Number: ?
Version: 1
Status: Developing (Last Call)
Reply-To: perl6-language @perl.org
This and other RFCs are available on the web at
http://dev.perl.org/
> > What exactly didn't you like about RFC 128???
>
> Ummm... the fact that its title doesn't match /proto/. My bad.
In fact it proposes that "prototype" be banished as a term of reference. :-)
> Okay, its a proposal to overhaul prototyping, cool. But I don't see
> anything
On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote:
>> I'm surprised there hasn't be a good overhaul of the prototyping
>> system proposeed yet.
>
> What exactly didn't you like about RFC 128???
Ummm... the fact that its title doesn't match /proto/. My bad.
Okay, its a prop
> I'm surprised there hasn't be a good overhaul of the prototyping
> system proposeed yet.
What exactly didn't you like about RFC 128???
Damian
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
> Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
I don't think this is enough to repair $SIG{__WARN__} and
$SIG{__DIE__}. I know some people out there have some very strong
feelings about these pseudo-signals. It may
Interesting point you made about context. $size = @array is typically
the first introduction of the idea of contexts to a new programer.
On Sat, Sep 16, 2000 at 03:38:47AM -, Perl6 RFC Librarian wrote:
> (2) require changes to the prototype system to permit length() to
> still be overridabl
On Sat, Sep 16, 2000 at 03:24:32AM -, Perl6 RFC Librarian wrote:
> Currently, trying to dynamically assign to unnamed classes is very
> difficult:
>
>$pkg::$var = $val; # error
>${pkg}::$var = $val; # nope
>${$pkg::$var} = $val; # you wish
>${${pkg}::$var} =
Nathan Torkington wrote:
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that ma
On Sat, Sep 16, 2000 at 03:37:33AM -, Perl6 RFC Librarian wrote:
> "%hash" should expand to:
>
> join( $/, map { qq($_$"$hash{$_}) } keys %hash )
So let me get this straight...
%hash = (foo => 42, bar => 13);
print "%hash";
should come out to:
foo 42
bar 13
The idea of inte
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
>> Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
MGS> I don't think this is enough to repair $SIG{__WARN__} and
MGS> $SIG{__DIE__}. I know so
Richard Proctor wrote:
> > Maybe I'm being too simplistic, I don't use tabs anymore.
> >
>
> Yes you are, the problem comes with mixing editors - some use tabs for
> indented material some dont, some reduce files using tabs etc etc. [I move
> between too many editors]. Perl should DWIM. I thin
Certainly I could live with this set of suggestions. The complete set. Thanks
Richard and Michael for developing them.
Michael G Schwern wrote:
> I'd say:
>
> 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the
>terminator, but it doesn't effect anything)
>
> 2) <<<
On Sat, Sep 16, 2000 at 03:20:23AM -, Perl6 RFC Librarian wrote:
> Perl used to use $pkg'var instead of the modern $pkg::var. This is still
> in Perl 5. It's gotta go.
Aside from "its old", is there any particular reason why $pkg'var
should go? The only reason I saw was that $hash{a'b} doesn
documentation
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Form a documentation working group to edit, clean, and produce
documentation
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 15 Sep 2000
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
IO: Standardization of Perl IO Functions to use Indirect Objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 239
Vers
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
length(@ary) deserves a warning
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 238
Version: 1
Status: Developing
Sup
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hashes should interpolate in double-quoted strings
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 237
Version: 1
Statu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
=head1 VERSION
Maintainer: Chris Hostetter <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 236
Version: 1
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
rindex and index should return true/false values
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Numbe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTEC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 195
Version: 2
Status: Froze
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: 15 Sep 2000
Mailing List: [EMA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Emit warnings and errors based on unoptimized code
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Num
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make length(@array) work
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
Number: 212
Version: 2
St
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More direct syntax for hashes
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 196
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix C<$pkg::$var> precedence issues with parsing of C<::>
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
> I loathe the indirect object syntax.
Well that makes one of us! ;-)
> Easy. Put them in a subroutine:
>
> sub format1 { format $template1, @data };
> sub format2 { print STDERR format $template1, @data };
> # etc.
Gag! Cough! Ack! :-}
Not trying to be mean, but this
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Legacy Perl $pkg'var should die
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 08 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 71
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace localtime() and gmtime() with date() and utcdate()
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 05 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTE
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Keep default Perl free of constraints such as warnings and strict.
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROT
> > prints the result to the current filehandle (in a void context).
>
> The last one I think needs to be able to work on any filehandle via
> indirect object syntax, namely:
>
>format $FILE "<<< [[[ [[",
> $title,
On Fri, Sep 15, 2000 at 11:25:31AM -0700, Steve Fink wrote:
> I agree. I'd like q/.../ to stick as close to giving me ... as possible.
> I can live with the current 'foo\\bar' having only one backslash in it,
> but I'd rather not have to worry about anything else. I'd vote for
> Glenn's allowing t
On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
> > The only decision, then, is to decide which context to use; if it
> > deparses to concatenation then it seems logical to use scalar context.
> > This also makes sense in that you can force list context with @{[
> > $weather->temp
On Fri, 15 Sep 2000 11:25:31 -0700, Steve Fink wrote:
>Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
It's an necessary evil. You need a way to escape the string delimiter,
so that it can be included in the string, for which the backslash is
used. Hence, you need to be a be to e
On Thu, 14 Sep 2000 21:06:24 -0700, Glenn Linderman wrote:
>However, let's look at it the other way. How about instead of trying to _extend_
>single quote semantics, that instead we find a way of _disabling_ double quote
>semantics? Let's say within double quotes that \D reverts to single-quote
> (?Q$foo) Quotes the contents of the scalar $foo - equivalent to
> (??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
On Fri, 15 Sep 2000 08:13:26 -0400 (EDT), Eric Roode wrote:
>The here-doc terminators all line up with the perl code.
>The generated program is nicely indented relative to the left margin.
My sentiments exaclty.
I think I would compare this to normal TV programmes (the code)
interruped by spec
On Thu, 14 Sep 2000 03:11:54 -0400, Michael G Schwern wrote:
>The current stumper, which involves problems 1, 2 and 3 is this:
>
> if( $is_fitting && $is_just ) {
>die Dulce et decorum est
> Pro patria mori.
>POEM
> }
>
>I propo
Simon Cozens wrote:
> sub interpolate {eval "\"@_\""}
>
> Never say "there is no way". There's *always* a way, and 99% of the time it
> doesn't need to go in core.
Yes. Well, actually if you carefully read the thread about RFC 111 in which I got
the inspired flash that interpolation of variable
> The only decision, then, is to decide which context to use; if it deparses
> to concatenation then it seems logical to use scalar context. This also
> makes sense in that you can force list context with @{[ $weather->temp ]} if
> you really wanted it.
$ perl -le 'sub w{wantarray?"WA":"WS"};pr
I'm happy with this solution, it seems to address everyone's needs.
-Nate
Michael G Schwern wrote:
>
> I'd say:
>
> 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the
>terminator, but it doesn't effect anything)
>
> 2) <<< does (e).
> This RFC proposes a support of a situation when a more-knowledgable module may
> steal overloading from a less-knowledgable module or visa versa;
What if both modules have this :override bit set at the same time? Does
the second one still win? Or does the first one win again?
Either way I'm no
> =head1 TITLE
>
> Data: Multi-dimensional arrays/hashes and slices
<...>
> =item *
>
> proposes a convenient syntax to slice multi-dimensional arrays;
>
> =item *
>
> proposes a convenient syntax create subobjects which behave as slices;
>
> =item *
>
> does it with as little overhead as possib
Jeremy Howard writes:
> > RFC : 196 v1; Developing
> > Title: More direct syntax for hashes
> > Maint: Nathan Torkington <[EMAIL PROTECTED]>
> > List : [EMAIL PROTECTED]
> > Date : 5 Sep 2000
>
> Discussion on this one has died down... Nat--could you incorporate the
> suggestions from the list a
Dan Sugalski wrote:
> 1) How fast is the C (or whatever) code it emits likely to be?
The perl-in-perl interpreter would not be a deliverable. Speed would
not be its goal. It would be a reference implementation that would be
easier to break and repair. An internals tutorial, if you will.
So
First off, nice proposal. :-) I haven't had a change to digest the
entire thing (although I did read it all), but I would like to add a few
things:
> returns the result as a single multi-line string (in a scalar context)
> returns the result as a list of single-line strings (in a
Adam Turoff wrote:
> I didn't use Date::Parse, but I did look for all RFCs still stting
> at v1 status. Since they're numbered chronologically, I cut off the
> bottom (anything submitted after 9/7).
>
> There are 100 RFCs in the list that follows. Code and data upon request.
>
Thanks Ziggy--very
> I think such modules are a bad idea, because their functionality is
> typically restricted.
What, you mean like CGI.pm ?! :-)
> This is a benefit? Forcing multiple authors to use the same 'this' or
> 'self' name across modules is not the perl way
Well, from this logically follows that "forci
> The current ideas tend to converge around
While reading the current rfc199.2 version I imagined another way
to do this. Instead of adding a new escape, what if we could
fiddle with the looping condition?
Given a grep that works like so:
sub mygrep(&@){
local $inde
On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote:
> Mark-Jason Dominus writes:
> > I think it would be a step in the right direction if the WG chairs
> > actually required RFC authors to maintain their RFCs.
>
> In preparation for the end-run of RFCing, how about we compile a lis
Chaim Frenkel writes:
> We are not at that stage yet.
>
> There are too many new things that are _supposed_ to interact to
> bother with a prototype. It doesn't do any good, until the language
> is nailed down.
That's no argument against prototyping, though. Prototype one feature
and then you
Mark-Jason Dominus writes:
> I think it would be a step in the right direction if the WG chairs
> actually required RFC authors to maintain their RFCs.
In preparation for the end-run of RFCing, how about we compile a list
of "developing" RFCs that haven't been touched in more than a week,
and con
Chaim Frenkel writes:
> I would like to have an undef returned.
Ah, I see. You want subroutines to return undef if they're given it
for any of their arguments. That'd break the lazy programmer practice
of passing undef expecting it to become "" or 0. They don't have
warnings on, of course.
Na
The discussion about RFC 227 in -internals brought up a few good ideas
about a taint pragma. In brief:
- taint(), tainted() and other such functions would be useful
when sending scalars around or inspecting them. A few other
functions may fall into this category.
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Version: 3
Mailing List: perl6-language
Number: 199
Status: Developing
=head1 ABSTRACT
Allow built-in functions and user de
Steve Fink writes:
> I suspect perl can do a much better job than it does now, but if you
> make it a requirement, you prevent many optimizations. I think the RFC
> should be very specific about when it applies and when it gets out of
> the way.
I can't be more specific unless I know the optimiza
My first preference is for overriding constant strings.
My second preference is to provide a user-defined quoting operator mechanism,
possibly as part of a user-defined operator mechanism.
My third preference is for a new operator.
I personally do not want to see q() screwed with.
Nat
At 05:21 PM 9/15/00 -0400, Chaim Frenkel wrote:
>I don't believe that the optree has to be bloated. I think having the
>actual line number in the optree vs. having a seperate structure
>mapping offsets to line numbers are the same.
>
>Then an error report would be akin to
> error_me_this(c
On Fri, Sep 15, 2000 at 05:04:23PM -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> >> But these all lack command line switches that are passed to perl.
>
> DS> No, they don't. Not everywhere, certainly. Command-line switches
> DS> can be passed to all of 'em
At 17:11 -0400 2000.09.15, Chaim Frenkel wrote:
>> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>
>>> This new module to cover your feature would require that it know every
>>> known epoch and timesystem (or at least the useful ones.) Something
>>> this domain knowledgable shouldn't be in
On Fri, Sep 15, 2000 at 01:33:01PM -0700, Nathan Wiger wrote:
> Michael G Schwern wrote:
> >
> > perl6-internals is probably the wrong forum for this, it was just
> > convenient. I think Dan's got the right idea, distribute a Taint
> > module with Perl.
>
> I'm not sure what's happened on -inte
I don't believe that the optree has to be bloated. I think having the
actual line number in the optree vs. having a seperate structure
mapping offsets to line numbers are the same.
Then an error report would be akin to
error_me_this(current_op_address, "Foo didn't baz in time. Aborting")
Perl6 RFC Librarian writes:
> This RFC proposes two-stage autoloading: one stage may be registered
> to act when the symbol is encountered at compile time, the other
> when the subroutine is called. Autoloading on the second stage does not
> I the subroutine, only I it.
You have a beautiful min
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> This new module to cover your feature would require that it know every
>> known epoch and timesystem (or at least the useful ones.) Something
>> this domain knowledgable shouldn't be in CORE.
CN> Why? File::Spec is in the core. So are m
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> But these all lack command line switches that are passed to perl.
DS> No, they don't. Not everywhere, certainly. Command-line switches
DS> can be passed to all of 'em. Not everyone counts on the magic
DS> shebang line to find the command
Dave Storrs wrote:
>
> As to solving problem #1 (which is, arguably, the bigger problem),
> suppose we add a new switch to perl? I propose we add the -H switch
> (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would
> be generated with a sufficient amount of bloat that
Michael G Schwern wrote:
>
> perl6-internals is probably the wrong forum for this, it was just
> convenient. I think Dan's got the right idea, distribute a Taint
> module with Perl.
I'm not sure what's happened on -internals, but early on in
perl6-language I suggested something similar, and Lar
On Fri, Sep 15, 2000 at 04:01:11PM -0400, Dan Sugalski wrote:
> >Anyhow, however these extra tainting functions are implemented is fine
> >(as long as they work). The simplest thing would be to just merge and
> >patch up Taint.pm and distribute it with perl6.
>
> Yup. I know Tom wanted an all-pe
At 15:55 -0400 2000.09.15, Chaim Frenkel wrote:
>CN> * We do not know if it will always be this simple for every platform
>
>Hard to see how the three variables wouldn't cover the spectrum.
Very hard to see, until we know what the disparate platforms might require. :)
>CN> * You might need to
On Fri 15 Sep, Michael G Schwern wrote:
> On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote:
> > 1) << removes whitespace equivalent to the terminator (e) this is largely
> > backward complatible as many existing heredocs are unlikely to have white
> > space before the terminator.
>
At 03:58 PM 9/15/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> Any time the code being executed isn't being run as the person asking for
>DS> its execution you can have problems. Think daemons in perl, or
>DS> client-server code. (Like CGI programs,
At 03:38 PM 9/15/00 -0400, Michael G Schwern wrote:
>On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> > Take a look at the Taint modules on CPAN. Mine does just these, and I
> think
> > Tom Phoenix's does a bunch more.
>
>Tom's Taint.pm has never worked for me. I just tried instal
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Any time the code being executed isn't being run as the person asking for
DS> its execution you can have problems. Think daemons in perl, or
DS> client-server code. (Like CGI programs, or mailing-list managers) Jobs run
DS> automagical
At 03:43 PM 9/15/00 -0400, Michael G Schwern wrote:
>On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote:
> > I'm kinda surfing the edge here. -T is definately an internals issue,
> > but $TAINT? taint()? is_tainted()?
> >
> > I'm not sure if they should be exposed into the language fro
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
>> my_time_in_local_epoc
>> + current_os_epoch_offset
>> - timezone_ofset_in_seconds
>> = time_in_unix_epoch_seconds
CN> But again, I don't know what you are trying to say. Are you saying we
CN> should have some global "constant"? If so, y
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> It may not be. Think CGI.
JH> The code is running under what ever poor security measures the silly
JH> subclued webmaster set it up to be, and has access to which ever files
JH> yadayadayada.
No command line switches there. Only t
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote:
> I'm kinda surfing the edge here. -T is definately an internals issue,
> but $TAINT? taint()? is_tainted()?
>
> I'm not sure if they should be exposed into the language from the
> internals, or if a superstudly taint.xs in stdlib i
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> Take a look at the Taint modules on CPAN. Mine does just these, and I think
> Tom Phoenix's does a bunch more.
Tom's Taint.pm has never worked for me. I just tried installing it
again and it failed a bunch of tests (in both 5.005 a
On Fri, 15 Sep 2000 08:28:30 -0700 (PDT), Dave Storrs wrote:
> Personally, I like the way it works at the moment; all the subs
>that you want to memoize are up at the top, where they are easy to see.
You have a point.
What I don't like is how the basic module syntax pretty much requires
t
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace Exporter by a better scaling mechanism
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 233
Version: 1
Stat
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: sprintf() with overloaded objects
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 235
Version: 1
Status: Dev
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace AUTOLOAD by a more flexible mechanism
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 232
Version: 1
Statu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: overloading via the SECOND operand if needed
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 234
Version: 1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Multi-dimensional arrays/hashes and slices
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 231
Version: 1
St
On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote:
> 1) << removes whitespace equivalent to the terminator (e) this is largely
> backward complatible as many existing heredocs are unlikely to have white
> space before the terminator.
>
> 2) <<< removes whitespace equivalent to the s
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternative lists and quoting of things
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 166
V
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace C built-in with pragmatically-induced C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 230
Version: 1
I thought you people might need a little break. The first one is
particularly... yeah.
- Forwarded message from Jim Monty <[EMAIL PROTECTED]> -
From: Jim Monty <[EMAIL PROTECTED]>
Subject: Re: [FWP] Comic goodness
To: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 09:53:48 -0700 (MST)
> See,
On Fri, 15 Sep 2000 12:01:55 -0400, Mark-Jason Dominus wrote:
>When you translate a script, the translator should translate things so
>that they have the same meanings as they did before. If it doesn't
>also translate eval, then your Perl 5 scripts will be using the Perl 6
>eval, which isn't wha
On Fri, Sep 15, 2000 at 02:11:55PM -0400, Dan Sugalski wrote:
> -c in there between the load-time things
> (-M, -T, -U, etc...) and the runtime things (-n, -p)
I'd say -c should be last, if only to keep Abigail happy:
% perl -nce '}print $.; {'
-e syntax OK
simon@deep-dark-truthful-mirror ~/p
Nathan Wiger wrote:
>
> Andy Dougherty wrote:
> >
> > How do you turn it off? I want to keep a way to specify stuff without any
> > interpolation whatsoever. I see the usefulness of this sort of quoting,
> > but I also see the usefulness of being absolutely able to turn all
> > interpolation off
It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
At 01:53 PM 9/15/00 -0400, Adam Turoff wrote:
>On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
> > At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
> > >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
> > > > I vaguely recall when Chip put that in. He worked pretty hard t
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
> At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote:
> >On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Extend the window to turn on taint mode
> >
> >As long as we're talking about t
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> The only reason I can see nice winning over fast is if nice brings in whole
> new concepts to the language. (Like, say, matrix ops or Damian's currying stuf)
Well, taking the idea of writing the parser in Perl, let's have a look
at
On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
> At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
> >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
> > > I vaguely recall when Chip put that in. He worked pretty hard to
> > > adjust the command line/#! option processing.
Bart Lateur wrote:
>
> On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>
> >Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
> >anything else sees it. So any features implemented in the tokenizer have
> >to get smarter about remembering what they did.
>
> This sound
1 - 100 of 150 matches
Mail list logo
