Nathan Wiger wrote:
Jeremy Howard wrote:
RFC 203 defines a :bounds attribute that defines the maximum index of
each
dimension of an array. RFC 206 provides the syntax @#array which returns
these maximum indexes. For consistancy, the arguments to reshape()
should be
the maximum index of
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 1
Status: Developing
=head1
Perl6 RFC Librarian (aka Damian Conway) wrote:
This RFC (seriously) proposes Perl 6 provide Cany and Call operators,
and, thereby, conjunctive and disjunctive superpositional types.
Great to see this RFC'd--this will makes lots of data crunching code _way_
easier.
Now, I haven't quite
Jeremy Howard wrote:
Do any() and all() have some magic around how they are implemented in von
Neumann computers that make them faster than standard CS searching
techniques?
I'm probably naive here but shortcuts in a non-parallelized (classical)
implementation rely on the usual
Do any() and all() have some magic around how they are
implemented in von Neumann computers that make them faster than
standard CS searching techniques?
I'm probably naive here but shortcuts in a non-parallelized (classical)
implementation rely on the usual
Chaim Frenkel [EMAIL PROTECTED] writes:
"AD" == Andy Dougherty [EMAIL PROTECTED] writes:
AD In my humble opinion, I think perl's time() ought to just call the C
AD library's time() function and not waste time mucking with the return
AD value. Instead, if the time is to be stored externally for
Andy Dougherty [EMAIL PROTECTED] writes:
On Thu, 14 Sep 2000, Charles Lane wrote:
On at least some non-Unix systems, the time() function is itself an attempt
to emulate Posix functionality...note that I say "attempt". And also note
Do you mean that the following program might not print '5'
At 11:01 -0400 2000.09.14, Andy Dougherty wrote:
On Thu, 14 Sep 2000, Chris Nandor wrote:
There's also the possibility of time accepting an argument, where 0 would
be perl's time and 1 would be native time, or something.
Now that's a clever idea. Hmm. I think I like it as a solution to the
At 11:15 -0400 2000.09.14, Charles Lane wrote:
I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
the default.
Well, Perl is about making things easy. What is the most common case,
needing an arbitrary value of time that may or may not be used to transfer
between platforms,
On Thu, 14 Sep 2000, Chris Nandor wrote:
Well, Perl is about making things easy. What is the most common case,
needing an arbitrary value of time that may or may not be used to transfer
between platforms, or needing a value of time that is specific to a given
platform?
And I cannot
"CN" == Chris Nandor [EMAIL PROTECTED] writes:
CN No, that won't really work. When my offset from GMT changes for daylight
CN savings time, it will break. The point of having a module is that epoch
CN conversions are more complicated than that. For example, Mac OS epoch
CN begins at Jan 1
Bart Lateur [EMAIL PROTECTED] writes:
Now, on those platforms without 64 bit support, a double float has a lot
more mantissa bits than 32, typically 50-something (on a total of 64
bits). This means that all integers with up to more than 50 significant
bits can exactly be represented. That
At 17:47 -0400 2000.09.14, Chaim Frenkel wrote:
"CN" == Chris Nandor [EMAIL PROTECTED] writes:
CN No, that won't really work. When my offset from GMT changes for daylight
CN savings time, it will break. The point of having a module is that epoch
CN conversions are more complicated than that.
"CN" == Chris Nandor [EMAIL PROTECTED] writes:
This is a wider
problem then a fixed epoch for perl. Let's turn this around. What if
we are on a platform that doesn't use perl's epoch and we need to write
a value to a file?
CN Yes. What if? That's what we're addressing. Right now, you
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 9 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
David L. Nicol wrote:
This ability to jump to "the right place" is exactly what exception handling
is for, as I understand it. Exceptions allow us to have one kind of block
and any number of kinds of exit mechanisms. If qC(last die return) are all
excpetions, the can travel up the call
'John Porter' wrote:
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from
RFC 186 is another interesting -io RFC, even though I'm not on the -io
list. I couldn't find any discussion in the mail archive, so here's
some to
start it. Please copy me on the discussion. Sorry for cross posting,
but
this is attempting to unify RFCs from different lists; I've bcc'd two of
On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
This RFC also seems to be related to RFC 183... using POD for testing. Now
the model of use apparently envisioned for RFC 183 is to have the tests
inside the POD, and then use a preprocessor to hack them out and put them in
Glenn Linderman wrote:
I have a number of scripts that use this sort of facility, using push/shift
to populate/read the array "file". These could be made simpler and more
general by wrapping the array as a file.
Perhaps the open "handler" stuff could be used to implement this?
Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
1) why extract it if it could potentially be used
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 04 Aug 2000
Last-Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) [EMAIL PROTECTED]
Date: 23 Aug
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
1) why extract it if it could potentially be used in place
2) if it cannot be used in place, then why bundle it
So I guess RFC 183 leaves me not understanding its goals. If there
is a benefit to the bundling, then RFC 183
"David L. Nicol" wrote:
File handles work perfectly well
right now as undecorated terms with well defined characteristics
Perfectly well?
* Have to use ugly globref syntax to pass them around reliably.
* Not first-class objects, so you can't subclass them.
* Special
Nathan Wiger wrote:
(in response to an assertion of preference for undecorated filehandles)
Well, I think you might be overlooking a couple of important things
about filehandles. First, having them NOT be scalars caused many
problems:
1. You must use globs to pass them in and out of
"David L. Nicol" wrote:
1. You must use globs to pass them in and out of functions
This could be resolved by allowing undecorated types to be passed
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a bareword
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern [EMAIL PROTECTED]
Date: 14 Sep 2000
Version:1
Mailing List: [EMAIL PROTECTED]
=head1 ABSTRACT
Method calls should interpolate in double-quoted strings, and similar
locations.
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
On Thu, Sep 14, 2000 at 03:57:41AM -0400, Michael G Schwern wrote:
Methods will be run in scalar context. A method which returns a single
I would suggest that anyone want to contribute to this discussion should
first read the thread about the addition of this pragma to perl5 in
the perl5-porters archives
http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragmaerrors=0case=onmaxfiles=100maxlines=30
Graham Barr [EMAIL PROTECTED] writes:
I would suggest that anyone want to contribute to this discussion should
first read the thread about the addition of this pragma to perl5 in
the perl5-porters archives
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Cmy Dog $spot is just an assertion
=head1 VERSION
Maintainer: Piers Cawley [EMAIL PROTECTED]
Date: 13th September 2000
Mailing List: [EMAIL
Nathan Torkington [EMAIL PROTECTED] writes:
Perl6 RFC Librarian writes:
I therefore propose that Cmy Dog $spot comes to mean that C$spot
is restricted to being either undefined or a reference to a CDog
object (or any subclasses of Dog). Simply having this implicit
assertion can be
Michael G Schwern [EMAIL PROTECTED] writes:
On Wed, Sep 13, 2000 at 08:43:43PM -, Perl6 RFC Librarian wrote:
The behaviour of the my Dog $spot syntax should simply be an
assertion of the invariant:
(!defined($spot) || (ref($spot) $spot-isa('Dog)))
What about the current
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
Yeah, I've got to split those up. I was trying cut down on the flood of
RFC's that poor Larry has to sift through :-(, but they are both
Nathan Wiger wrote:
use namespace 'Big::Long::Prefix';
my ::Class $object = ::Class-new;
Assuming repairing :: precedence is a reality I don't think this
proposal buys us anything.
backtracking...That being said, I'm not necessarily against it. I'm
just against bloat. I hadn't
Michael G Schwern [EMAIL PROTECTED] writes:
print "Today's weather will be $weather-temp degrees and sunny.";
This does not DWIM. Instead of interpolating C$weather-temp as a method
call, it comes out as C$weather.'-temp' and is usually followed immediately
by the question "What does
Piers Cawley writes:
TBH, I'm not sure I want to go too far down that road in this RFC. And
tbh they seem more like internals issues to me. The runtime behaviour
this change grants is good enough for me and I don't want to see the
proposal bogged down in flamage about strict types. Of course,
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
print 'Today\'s weather will be '.join($", $weather-temp()).
' degrees and sunny.';
However if temp() calls wantarray(), the result will be FALSE (scalar).
I think what he's trying to get at is that these
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects should have builtin stringifying STRING method
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 06 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
package Dog;
use fields qw(this night up);
my Dog $ph = [];
$ph-{this} = "that";
That works? I thought you had to do:
my Dog $self =
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern [EMAIL PROTECTED]
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head1
First of all, I think this is a great idea
On 14 Sep 2000, Perl6 RFC Librarian wrote:
Are there any contexts besides double quotes ("", qq{}, "EOF") where this
need be applied? What about inside regexes? And if so, left and/or right
hand side?
Regexes are enough like double quoted strings
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 189
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing Cref, Cattribute::reftype, and Cbuiltin::blessed
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number:
Piers wrote:
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like Cuse base 'Interface' but with
'Interface' consisting of nothing but:
At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
Piers wrote:
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like Cuse base 'Interface' but with
'Interface'
On Thu, Sep 14, 2000 at 06:37:22PM -0500, David L. Nicol wrote:
A possibility that does not appear in RFC222.1 is to put tho whole
accessor expression inside curlies:
print "Today's weather will be ${weather-temp} degrees and sunny.";
which would follow the "You want something funny
=head2 The CBUILD method
=head3 The CREBUILD method
Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
that we all like! :-(
-Nate
=head2 The CBUILD method
=head3 The CREBUILD method
Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS
that we all like! :-(
Oops. You're correct. I will rectify that.
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern [EMAIL PROTECTED]
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head1
On 30 Aug 2000 02:13:38 -, Perl6 RFC Librarian wrote:
Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
Why?
What's next, replace the regex syntax with something that more closely
ressembles the rest of Perl?
Regexes are a language within the language. And not a tiny
On Thu, 14 Sep 2000 08:47:24 -0700, Nathan Wiger wrote:
One thing to remember is that regex's are already used in a number of
functions:
@results = grep /^VAR=\w+/, @values;
You are being mislead. You might just as well say that length() is being
used in other functions:
@results =
I'm opposed to an obligation to replace m// and s///. I won't mind the
ability to give a prototype of "regex" to functions, or even
*additional* functions, match and subst.
As the RFC basically proposes. The idea is that s///, tr///, and m//
would stay, seemingly unchanged. But they'd
In RFC 72, Peter Heslin gives this example:
:Imagine a very long input string containing data such as this:
:
:... GCAAGAATTGAACTGTAG ...
:
:If you want to match text that matches /GA+C/, but not when it
:follows /G+A+T+/, you cannot at present do so easily.
I haven't tried to work it out
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 17 August 2000
Last Modified: 14 September 2000
On Wed, 13 Sep 2000 19:57:28 -0700, Nathan Wiger wrote:
Perl should stop nagging about this. Perl should be smart and not bother
you about uninitialized values in the following situations:
- string concat
- string comparison
Allow me to disagree. In my case, I mostly use variables in
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace
This would HAVE to be a very optional feature. I rely on undef
converting to a null string in many, many programs.
Surely in those programs you don't have -w turned on, because you wouldn't
want to see all those warning messages. So here is another idea: -w causes
string interpolation
Nathan Wiger wrote:
I don't know about this. What if someone writes:
print "You owe me $2, $name.\n";
With -w it'll print out the "correct" version?
With a warning, because $2 isn't defined.
You owe me $2, Nate.
But without it it won't?
You owe me , Nate.
You turn off
On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
The rest is handled adequately and consistently today, and Tom's
dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "mod 8"
(which it does).
Damnit, I'm
On 13 Sep 2000, Perl6 RFC Librarian wrote:
An inconsistency between "Cprint" and "" bugs me: "Cprint;" means
"Cprint $_;" so it seems like "" should mean "C$_ = ".
This would break code prompting for "Press any key" and wasting the
input.
I suggest again:
s/""/"C "/g; s/C$_ = /C $_ =
Michael G Schwern [EMAIL PROTECTED] writes:
[...]
I propose that this work out to
"The old lie\n Dulce et decorum est\n Pro patria mori.\n"
and always work out to that, no matter how far left or right the
expression be indented.
{ { { { {
if(
On 13 Sep 2000, Perl6 RFC Librarian wrote:
=head1 DESCRIPTION
$_ is the default scalar for a small set of operations and functions.
Most of these operations and functions are ones that use C=~.
Er, no. Quite a few others also use $_. The ones I found: -X filehandle
tests (except for -t),
I've implemented a prototype of the indented here-doc tag I'm proposing.
http://www.pobox.com/~schwern/src/RFC-Prototype-0.02.tar.gz
Its RFC::Prototype::111, which is probably the wrong number.
I'll have to add POD =~ s/// syntax. Also, if anyone's good with
filters I couldn't quite get the
Michael,
I just noticed your post (I am at work). This is begining to get there (maybe I
should not have split the original
111).
In the prototype you only cover use of " quotes.
if( ($pre_code, $quote_type, $curr_tag, $post_code) = $_ =~
m/(.*)\\(")(\w+)"(.*)/ )
It needs to match
use diagnostics;
my $i=1;
print 'hi' if ($i=1;
running this with perl -wc (v 5.004, unix), I get
perl -wc x.pl
syntax error at x.pl line 3, near "1;"
x.pl had compilation errors (#1)
(F) The final summary message when a perl -c fails.
Uncaught exception from user code:
Glenn Linderman wrote:
Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC
On Thu, 14 Sep 2000 12:16:51 GMT, Ed Mills wrote:
If I'm missing a "}" the compiler tells me its missing. That's also a syntax
error, but it reports the actual missing "}". Why not do the same for ")"?
That reminds me: if Perl reports a missing "}", "]" or ")", it would
also be very nice if
Sometimes I want a chunk of documentation to hang out near a
chunk of code, but the order of the code is not always a good order for
a man page.
Are you familiar with the Cdivert m4 command? Lm4.
I'm not saying it would be the way to go; but it might be useful
to see how another
Chaim Frenkel wrote:
Removing -1 as a valid result, could be a breakage (if someone is
doing something weird with a negative result)
What, like using it as an index into a substr?
Bad Code is its own reward, my friend.
$foo = "flabergasted";
substr($foo, index($foo, 'abc'),
Ariel Scolnicov wrote:
1. It requires the perl parser know about indentation. Of course we
all know that tabs are 8 characters wide (I myself make a point of
bludgeoning anyone who says otherwise), but do we really want to
open this can of worms?
Not so fast with those 8-column tabs.
In Michael Schwerns prototype, expansion to treat both semicolons and comments
at the end tag is possible by changing
/^(\s*)$curr_tag\s*$/
to
/^(\s*)$curr_tag\s*(;\s*)?(#.*)?$/
Richard
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But I'll need
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines and map/grep
blocks) from either of those. But
David L. Nicol wrote:
"Randal L. Schwartz" wrote:
I think we need a distinction between "looping" blocks and
"non-looping" blocks. And further, it still makes sense to
distinguish "blocks that return values" (like subroutines
and map/grep blocks) from either of those. But I'll need
Garrett Goebel wrote:
Could someone shoot down or prop up the following:
* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
Jarkko Hietaniemi wrote:
In the other camp, Cyield has been suggested; but
the conflation of that with its thread-related semantics may not
be a such good idea.
Cpass.
Well, "pass" might be o.k.; but it usually means something going
*into* a sub, not coming out...
--
John Porter
Eric Roode wrote:
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
Yes. This is a serious downside to the proposal, even
On Thu, Sep 14, 2000 at 11:46:31AM -0400, 'John Porter' wrote:
Jarkko Hietaniemi wrote:
In the other camp, Cyield has been suggested; but
the conflation of that with its thread-related semantics may not
be a such good idea.
Cpass.
Well, "pass" might be o.k.; but it usually means
Garrett Goebel wrote:
* Subroutines automatically get their name as a label
My concern here is whether it introduces a problem with Cgoto foo
vs. Cgoto foo. If, as you propose, subs do get their name as label,
I would like to conflate these two forms. But the semantics of
Cgoto foo
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus [EMAIL PROTECTED]
Date: 11 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 2
Status: Developing
If there are no objections, I will freeze this in
From: John Porter [mailto:[EMAIL PROTECTED]]
Eric Roode wrote:
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
On 14 Sep 2000, Ariel Scolnicov wrote:
1. It requires the perl parser know about indentation. Of course we
all know that tabs are 8 characters wide (I myself make a point of
bludgeoning anyone who says otherwise), but do we really want to
open this can of worms?
No,
Show me where this fails and I'll shut up about it.
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Before you scream "Bloody murder",
At 10:52 AM 9/14/00 -0700, Nathan Wiger wrote:
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
I have thought this before, but I think the
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving
Nathan Wiger wrote:
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
Richard Proctor made some excellent comments, and asked:
When measuring whitespace how does the system treat tabs? (be realistic
and dont FLAME)
I suggest that there be NO tab/space conversion. Not 8 columns, not
4 columns, nothing. If the here doc terminator has four tabs preceding
it, then
Eric Roode wrote:
I suggest that there be NO tab/space conversion.
I also suggest that no whitespace stripping/appending/etc/etc be done at
all. If I write:
if ( $its_all_good ) {
print EOF;
Thank goodness this text is centered!
EOF
}
That should print
Nathan Wiger wrote:
I also suggest that no whitespace stripping/appending/etc/etc be done at
all. If I write:
[...deletia...]
But this shouldn't be implicit in the language.
That's a good argument for having a separate operator for these
"enhanced here docs", say , rather than chucking the
Michael G Schwern wrote:
On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
The rest is handled adequately and consistently today, and Tom's
dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "mod 8"
On Thu, 14 Sep 2000 11:58:46 -0400, Mark-Jason Dominus wrote:
If there are no objections, I will freeze this in twenty-four hours.
Oh, I have a small one: I feel that this speudo-random salt should NOT
affect the standard random generator. I'll clarify: by default, if you
feed the pseudo-random
On Thu, 14 Sep 2000 10:52:16 -0700, Nathan Wiger wrote:
We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
With your above functions, you always need to be able to escape the
string end delimiter. Therefore, you will
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving
This reminds me of a related but rather opposite desire I have had
more than once: a quotish context that would be otherwise like q() but
with some minimal extra typing I could mark a scalar or an array to be
expanded as in qq().
I have wanted that also, although I don't remember why
On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
I'm all for solving problems, and this message attempts to specify 3
problems, but it needs more specification. You describe three
problems, but it is not clear what the problems are
Since we've been charging back and forth
John Porter wrote:
Chaim Frenkel wrote:
Removing -1 as a valid result, could be a breakage (if someone is
doing something weird with a negative result)
What, like using it as an index into a substr?
Bad Code is its own reward, my friend.
$foo = "flabergasted";
Nathan Wiger wrote:
Solves problem #1, indented terminator, except that it adds two newlines
(more later).
I never found anything later about these extra newlines... so if this idea
has merit, it needs to be finished.
However, it leaves 2 and 3. Let's try adding in a regexp:
if(
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Cuse invocant pragma
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 223
Version: 1
Status: Developing
1 - 100 of 138 matches
Mail list logo
