[Reply-To set to [EMAIL PROTECTED]]
Ed Mills wrote:
I actually saw this in the newsgroups and thought it was a neat idea. What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
You can currently get
On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
So you see why we need a persistent format() function. However, I think
your real issue is a one-time call that just changes the format
temporarily:
print $date-strftime('%H:%M'); # print the time
print "$date";
...and as for matching regexen against streams, I have a more general
proposal for matching against subroutines that should allow for that
as a special case.
Damian
Damian Conway sent the following bits through the ether:
Rather than continue to argue the details, why don't people post some
examples of code where they feel these lazy lists might be useful, and
let's see if there aren't already good alternatives.
It should be noted that "infinite"
Bart Lateur [EMAIL PROTECTED] writes:
The problem is that you can't safely subclass a class, without examining
it's source, just to make sure that your instance fields don't clash
with any private fields of the mother class.
Well...let's think twice. What has the reputatin of being a bug or
On Sun, Aug 06, 2000 at 09:36:12PM -0400, Ken Fox wrote:
Perl6 RFC Librarian wrote:
BiDirectional Support in PERL
I know nothing about bi-directional output. It doesn't seem
like Perl has any assumption of left-to-right at all. What's
the difference between right-to-left support in Perl
On Sun, 6 Aug 2000 18:28:29 -0800, Michael Fowler wrote:
print $pw;
print scalar $pw;
These resulting in a $pw-STRINGIFY or $pw-TO_STRING call is also
confusing; neither are being used as strings.
Oh yes they are.
$^W = 1;
my $x;
print $x;
This complains of
On Sat, Aug 05, 2000 at 04:10:20AM +1000, Damian Conway wrote:
If a switch is considered like a loop then next would be the same
as 'break' in C, as would last and redo would repeat the switch.
But a switch is not a loop.
True, but in perl any block is considered to be a loop that
Dan Sugalski [EMAIL PROTECTED] writes:
At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
Another one for my wish list: deep copying support built in. A devil
inside me thinks this should be a new assignment
operator. Damian? Sounds like this is up your alley. I want to do a
Lisp, which you might expect would have a 'deep copy' operator,
doesn't have one. The Lisp folks have apparently thought about this
very carefully, and decided that the semantics are unclear, and that
the obvious options are all wrong; I've read a number of articles
about this in the past.
I
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
Basically, you don't want to go anywhere near this mess; it eats people.
I agree.
I see two reasonable options to go with instead. One is to just use a
On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:
I
think the concept's great, just that the notation is really hard to
read, and doesn't necessarily scream "function" to me (especially since
_ is from stat already).
I don't see why you can't simply use _. From the context, you clearly
On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote:
Seems to me that a leading _ is worse for this than ^
Whatever prefix you choose, it should NEVER EVER be a \w character.
And the general rule, until now at least, is that only characters from
the ASCII repertoire are acceptable for
Nick Ing-Simmons wrote:
John Porter [EMAIL PROTECTED] writes:
my integer $quux = 4;
I believe that would have to be
integer my $quux = 4;
at least in perl5...
Well Larry has been using
my Dog $spot;
for a while.
O.k., I see that now; I was thinking 'integer',
Please post further MLC remarks to the MLC sublist:
[EMAIL PROTECTED]
I can't guarentee that any MLC comments posted under a different subject,
and on a different list will make it into the final Multiline Comments RFC!
Not to mention that this specific argument is already addressed in the
Thus it was written in the epistle of Bart Lateur,
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
If we've decided that chomp isn't going to return the clippings, would it not
seem prudent to make
while (chomp(ARGV))
work like
while (ARGV)
You mean, like, the -l command
Whatever you do, don't use those timezone names. Is EST Eastern US time
or Eastern Standard Time in Australia? The same abbreviation is used in
both places.
Naming of time zones is a *huge* rathole that you probably just don't want
to crawl into. The short abbreviations are *not*
On Mon, Aug 07, 2000 at 02:53:17PM +0200, Bart Lateur wrote:
On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:
I
think the concept's great, just that the notation is really hard to
read, and doesn't necessarily scream "function" to me (especially since
_ is from stat already).
I
Ken Fox wrote:
I think we need a curry context and that all curries must be surrounded
by parens.
.
sub traverse ($_);
my $sum = 0;
$root-traverse(($sum += __));
I think parens may be problematic, since nested lists flatten.
Maybe curlies could be overloaded yet again?
Jeremy Howard wrote:
Yes, I change my mind sounds of gears clicking I like the '^' prefix
too. The difficulty of reading __ would be a pain.
But what happens here?
/^__foo/
Or here?
/^{__}foo/
Is the latter sufficiently unambiguous?
--
John Porter
Nathan Wiger wrote:
Yeah, I personally can read this much clearer. Peter also mentions that
__ is hard to distinguish from _, unless they're right next to each
other, and I think this is a very valid point.
This biggest problem with '__', imho, is that '_' is a valid identifier
character.
Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
going away, it's available (right?).
It the "wildcard" mnemonic value is consistent with "placeholder".
--
John Porter
Jeremy Howard wrote:
Yes, they're not identical. What I mean of course is:
(..-1) == reverse(map -__ (1..));
WHAT? So the semantics of .. are magically different in the context
of (..$n) so as to produce numbers in descending order?
I don't think so.
--
John Porter
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
=head1 DESCRIPTION
At present Cindex only returns the index of the first occurrence of a
specified substring. It is proposed that Cindex take a fourth parameter
telling it which occurrence of a specified substring to locate:
$first =
At 11:40 AM 8/7/00 -0400, Michael Mathews wrote:
In the MLC discussion I have read many comments about how various "C-style"
features would be easier for people to learn, remember, and use. In fact the
MLC discussion itself was inspired by a desire to make Perl more C-like
(actually Java-like) in
$want_deep_copy++;
$want_deep_equal++;
From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]]
Lisp, which you might expect would have a 'deep copy' operator,
doesn't have one. The Lisp folks have apparently thought about this
very carefully, and decided that the semantics are unclear, and
John Porter writes:
Compilation: Remove requirement for final true value in require'd and
do'ed files
Do not. I use this feature.
Is there any reason you couldn't use "die" instead?
Nat
Nathan Wiger [EMAIL PROTECTED] writes:
But it isn't "here" that's the problem. If we just wanted to change
the value "here", we could use my(). The problem is that local()
changes the value for somewhere else as well as here.
Well, as has been pointed out, special^Wlocalized
Nathan Torkington wrote:
John Porter writes:
Compilation: Remove requirement for final true value in require'd and
do'ed files
Do not. I use this feature.
Is there any reason you couldn't use "die" instead?
???
Throw an exception in order to return a (0|'')-but-true value?
--
Just a quick tangential comment: it should be possible to specify the
maximum number of characters that a readline() will do on a filehandle. I
couldn't find this in IO::Handle which seems to be where the user-defined
line disciplines are inheriting their methods? Anyway, obvious application
John Porter writes:
Compilation: Remove requirement for final true value in require'd and
do'ed files
???
Throw an exception in order to return a (0|'')-but-true value?
If you want to indicate that there was an error in the code, why not
die()? What am I missing?
Nat
I don't see the point. What makes you want to do this?
And if you are changing it, why not make it return the list of matches
in a list context?
$last = (index $string, $substring)[-1]
(These type of translations/idioms might be candidates for optimization.)
chaim
"PRL" == Perl6 RFC
There are a wide range of tricky problems associated with deep copy and
deep compare. I like the idea, but circular references can make this
problematic even without external things (filehandles, dirhandles, objects
from non-perl sources) are thrown in. That needs to be taken into account
This seems to be adding a special case. (I.e. only if _both_ are
non-numeric will it switch to a cmp operation.)
I currently fail to switch to 'eq' many times when I should, but the
failure mode is obvious. Her the failure mode will be really strange.
(And how does one tell if the string is
Nathan Torkington [EMAIL PROTECTED] writes:
John Porter writes:
Compilation: Remove requirement for final true value in require'd and
do'ed files
Do not. I use this feature.
Is there any reason you couldn't use "die" instead?
Is there any reason that both couldn't be used at the
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
There are a wide range of tricky problems associated with deep copy and
deep compare. I like the idea, but circular references can make this
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_NetZero
If you're going to use a convention, rather than a syntax, then the current
convention of all CAPS reserved to Perl is easier to understand, more
pleasing to the eye, and backwards compatible.
Good point. Maybe we're getting a little "fix-happy". :-)
-Nate
At 10:29 AM 8/7/00 -0700, Nathan Wiger wrote:
With the proliferation of special subroutine names (BEGIN, END, INIT,
CHECK, etc.) the all capital subroutine names available to the
programmer has steadily shrunk. Rather than stealing subroutines from
the programmer, we should create a
John Porter writes:
But I admit this could be regarded as an edge case.
Yeah, you could easily make this part of the module's interface.
Removing the eval-to-true requirement would be one less arbitrary
thing for people writing modules to do, and I'm very in favour of
that.
Nat
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
There's a lot of cool time/date stuff, but
At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote:
On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
sub *BEGIN { ... }
sub *END{ ... }
sub *INIT { ... }
sub
This RFC proposes that numeric comparison operators default to stringwise
comparison when both arguments are non-numeric strings.
The problem with this, is that we're removing orthogonality from the
language.
ROTFL.
Do we want to say:
$num1 == $num2 works
Leon Brocard wrote:
Perl6 RFC Librarian sent the following bits through the ether:
affected files. I suggest that in a list context, they return the Inames
of the Iunsuccessfully affected files.
This seems the wrong way around to me. Surely it should instead return
the name of the
proposed:
@b = pop @a, $n;
should this be equivalent to:
@b = splice @a, -$n; # no longer a LIFO queue
or :
@b = reverse splice @a, -$n; # still a LIFO queue
I guess it all depends on what you then do with @b, but you get my drift.
This should be addressed, one way or another.
-Aaron
Damian Conway wrote:
This RFC proposes that numeric comparison operators default to stringwise
comparison when both arguments are non-numeric strings.
The problem with this, is that we're removing orthogonality from the
language.
ROTFL.
But it's true.
The
Peter Scott wrote:
Have often wanted a way to tell whether a scalar was a number, and rolling
a regex each time seemed wasteful given that Perl knew what it was
anyway. So a user-friendly way to get at the SvIOK and SvNOK results would
be great.
The pedestrian way would be a builtin:
Peter Scott wrote:
Have often wanted a way to tell whether a scalar was a number, ...
So a user-friendly way to get at the SvIOK and SvNOK results would
be great.
This is one of those rare proposals which can safely be assumed to
be proposed, discussed, and accepted without dissent -- before
At 12:27 PM 8/7/00 -0700, Peter Scott wrote:
Have often wanted a way to tell whether a scalar was a number, and rolling
a regex each time seemed wasteful given that Perl knew what it was
anyway. So a user-friendly way to get at the SvIOK and SvNOK results
would be great.
The Sv?OK macros
At 01:27 PM 8/7/00 -0400, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
There are a wide range of tricky problems associated with deep copy
and
deep compare. I
On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote:
I wrote a WWW mail program with hebrew support once. Pain in the ass to
invent and reinvent functions for printing Hebrew correctly. Moreover, a
lot of self-written reversing and replacing reduces the performance from
what it would be
Andy Dougherty wrote:
On Mon, 7 Aug 2000, Glenn Linderman wrote:
Me too, and I'm _not_ an astronomer.
Tim Jenness wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
It isn't that
I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:
package Foo;
sub new { bless {
On 7 Aug 2000 14:28:03 -, Perl6 RFC Librarian wrote:
Compilation: Remove requirement for final true value in require'd and do'ed files
Er... "do'ne" files?
Anyway, There is at least one case where you need this true value: if
the file accidently is empty (or equivalent). I've had that
Aaron J Mackey [EMAIL PROTECTED] writes:
proposed:
@b = pop @a, $n;
That will change the behaviour of this perl5 code:
foo(pop @a, "bar")
If we do this then the code above need to be fixed by the perl5-perl6
filter.
Regards,
Gisle
Anyway, There is at least one case where you need this true value: if
the file accidently is empty (or equivalent). I've had that happen.
A true value indicates that the file is indeed valid Perl.
So is an empty file! :-)
Damian
=head1 TITLE
Safe Signals
=head1 VERSION
Maintainer: Uri Guttman [EMAIL PROTECTED]
Date: 07 Aug 2000
Version: 1
Mailing List: perl6-language-flow
Number: TBD
=head1 ABSTRACT
This RFC describes how Perl6 can support safe signals with multiple
techniques.
=head1
On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote:
Right, VAX is strictly little-endian.
I.e. the address of a *word is the address of its least significant byte.
(That's little-endian, isn't it?)
Right. Why you people don't call it "Intel" vs. "Motorola", like the
rest of the civilised
"DC" == Damian Conway [EMAIL PROTECTED] writes:
I currently fail to switch to 'eq' many times when I should, but the
failure mode is obvious. Her the failure mode will be really strange.
DC I would claim that the failure mode is not obvious: "dog"=="cat" is true
Sure it is. I pass a
On 4 Aug 2000 14:59:06 -, Perl6 RFC Librarian wrote:
%special = ( woohoo = 1, d'oh = 1 );
while () {
switch ($_) {
case (%special) { print "homer\n"; last } # if
$special{$_}
Hold it. Is that
if($special{$_}) { ...
Bart Lateur wrote:
Anyway, There is at least one case where you need this true value: if
the file accidently is empty (or equivalent). I've had that happen.
A true value indicates that the file is indeed valid Perl.
That is a "lie", of the sort that Randal might tell you in day 1
of his
You missed part of his missive.
He mentioned two different encodings. Logical and Visual. I'm not clear
which is which. One orders the characters so that the first char is
first. The other reorders the characters to correctly display on a
device that can not understand rtl text.
chaim
"BL"
On 07 Aug 2000 17:27:55 -0400, Chaim Frenkel wrote:
He mentioned two different encodings. Logical and Visual. I'm not clear
which is which. One orders the characters so that the first char is
first. The other reorders the characters to correctly display on a
device that can not understand rtl
On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote:
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp(FILEHANDLE)) {
. . .
}
should become the equivalent of
while (FILEHANDLE) {
chomp;
. . .
Thus it was written in the epistle of Bart Lateur,
On 7 Aug 2000 16:06:44 -, Perl6 RFC Librarian wrote:
This RFC contains two proposed changes. First, as it is common to want to
removed newlines upon reading a file,
while (chomp(FILEHANDLE)) {
. . .
}
should become the
At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
I meant that BEGIN, END, and INIT aren't declared as subs at present but
named blocks. I was surprised to discover that they're put in the symbol
table anyway though.
Check the docs again.
John Porter wrote:
Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
going away, it's available (right?).
It the "wildcard" mnemonic value is consistent with "placeholder".
Yes, it's been suggested, but we might be too late on that one--another RFC
suggests reserving '*'
At 08:19 AM 8/8/00 +1000, Jeremy Howard wrote:
John Porter wrote:
Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
going away, it's available (right?).
It the "wildcard" mnemonic value is consistent with "placeholder".
Yes, it's been suggested, but we might be too
On Tue, Aug 08, 2000 at 06:22:03AM +1000, Damian Conway wrote:
I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields.
[snip]
See the Tie::Securehash module for a variation on this theme.
Also note
On Mon, Aug 07, 2000 at 01:57:14PM +0200, Jean-Louis Leroy wrote:
package Foo;
sub new
{
bless { "${CURRENT_PACKAGE}name" = 'Simpson' ...
}
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
Is $CURRENT_PACKAGE any different, value-wise,
On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote:
A true value indicates that the file is indeed valid Perl.
So is an empty file! :-)
That is precisely the problem. You won't get a syntax error if this
happens.
Now, bringing in the
From: Peter Scott [mailto:[EMAIL PROTECTED]]
At 12:07 AM 8/8/00 +0200, Bart Lateur wrote:
On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote:
Check the docs again. [snip]
Four special subroutines act as package constructors and
destructors. These are the `BEGIN', `CHECK', `INIT', and
On Mon, 07 Aug 2000, Damian Conway wrote:
$last = index $string, $substring, -1, -1;# last occurence
Err... shouldn't that be
$last = index $string, $substring, 0, -1 # last occurrence
$first = index $string, $substring, -1, -1 # first
2000-08-07-19:22:59 Michael Fowler:
Is $CURRENT_PACKAGE any different, value-wise, than __PACKAGE__?
I'm guessing no, unless I've misunderstood something from the
preceeding discussion.
Is there a reason to prefer it?
I suppose some folks who want to do a truly stunningly huge amount
of this
On Mon, 07 Aug 2000, iain truskett wrote:
Who here has actually used something other than a constant '1' in a
package?
If so, why? (Possibly cite the code.)
I have.
I've used 34. (Just 'cause I like the number.)
I've also used the filename before. (I wanted to watch the order of
I actually saw this in the newsgroups and thought it was a neat idea. What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
Thank-You for consideration, great ideas I'm seeing here!
-Ed
expr1 expr2
...and detects that the LJ is overloaded, it could replace it with:
user_defined_and( sub { $expr1 }, sub { $expr2 } )
Along the same line it would be useful to be able to overload the "truth
operator" (bad word, I'm sorry). It's great to be able to do:
It shouldn't be a problem. *_ would then be a 'special' reserverd identifier.
*_name could be a named placeholder.
chaim
"JH" == Jeremy Howard [EMAIL PROTECTED] writes:
JH John Porter wrote:
Has anyone suggested '*'? Since its use for typeglobs is (repsumably)
going away, it's available
Too special purpose.
I assume you don't do
print "foo\nbar\gasp\n";
very often.
chaim
"EM" == Ed Mills [EMAIL PROTECTED] writes:
EM I actually saw this in the newsgroups and thought it was a neat idea. What
EM about
EMprintln $textvar;
EM instead of
EMprint
So is this a consensus?:
It is proposed that Perl introduce a new prefix '^', which indicates a
placeholder. This can be used in any of the following ways:
- ^identifier: named placeholder
- ^_: anonymous placeholder
- ^0, ^1, ...: positional placeholder.
I think this sounds good -
As for the regexp issue, just to clarify there's only one ambiguous case
we need to work out that I can see:
/.*^foo/; # ok
But:/.*^foo/m; #ambiguous
We could undo the ambiguity like so:
/^{foo}/; # like ${foo} and @{foo} and %{foo}
In fact,
We could undo the ambiguity like so:
/^{foo}/; # like ${foo} and @{foo} and %{foo}
In fact, this seems built-in if we follow the same var conventions.
We
can make ^ bind to {} as tightly as we need.
That would be the right solution. And of course one could use
And there's no argument about having anonymous, positional, and named
placeholders in the redraft...?
There's *always* arguments! ;-)
Personally, if we have positional placeholders I don't see the need
for named ones too. But I'm willing to be convinced.
Damian
Damian Conway wrote:
And there's no argument about having anonymous, positional, and named
placeholders in the redraft...?
There's *always* arguments! ;-)
Although arguments from the RFC author are generally more compelling ;-)
Personally, if we have positional placeholders I don't
Jeremy Howard wrote:
Damian Conway wrote:
Personally, if we have positional placeholders I don't see the need
for named ones too. But I'm willing to be convinced.
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm willing
I'd agree to the contrapositive: if we have named placeholders, I don't see the
need for positional ones too. But I'm willing to be convinced. The below, with
positional only, is total gibberish, as Ken points out.
To most, probably, but I say let the user decide. Like Jeremy points
out:
[Reply to perl6-language-io as this is an I/O
related.]
Michael Mathews wrote:
Here's a thought. Wouldn't this be cool (see below)?
The idea is that in
Perl 6 you should be able to read from a file handle
one character or one
line at a time (just like you can in Perl 5) BUT if
you just go
On Mon, 7 Aug 2000, Tim Jenness wrote:
Is localtime() used often enough to justify being part of
the language?
You're kidding, right?
We wouldn't have had all those script kiddies complaining about year 19100
bugs and month-being-off-by-one errors if localtime() wasn't being used
all of the
John Porter wrote:
Glenn Linderman wrote:
When using an inline comment, I want to spend my character budget mostly
on the comment, and just enough on the delimiters to see it
effectively. # magic here # would do quite nicely
When reading a script, I'd like to be able to quickly
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons [EMAIL PROTECTED]
Date: 3 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 17
CVSID:
On Mon, 7 Aug 2000, Nathan Wiger wrote:
Also, I would vote for a method to return the Julian date (yes I am an
astronomer...) :-)
But surely not as a part of the core language?
Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core.
When writing RFCs that talk about the inclusion of "interesting" new
features--things like coroutines, matrix math, bizarre regex theory (yes, I
know that's redundant), curried (or garlic'd, or peppered) subs, for
example--it would be helpful if there was a good reference in the
references
don't cc to language
i have not seen any posted (on dev.perl.org) rfc's on exception handling
or errors. i would like someone to take one or both on and post it to
flow. there was some discussion in language on those subjects but the
threads have petered out (or have been drowned :-).
so let's
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Polymorphic comparisons
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 7 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 54
=head1 ABSTRACT
This RFC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Compilation: Remove requirement for final true value in require'd and do'ed files
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 7 August 2000
Version: 1
Mailing List: [EMAIL
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Optional 2nd argument to pop() and shift()
=head1 VERSION
Maintainer: Jonathan Scott Duff [EMAIL PROTECTED]
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 56
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Cchomp() changes.
=head1 VERSION
Maintainer: Ted Ashton [EMAIL PROTECTED]
Date: 7 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 58
=head1 ABSTRACT
The current return value of
[Reply-To set to [EMAIL PROTECTED]]
Ed Mills wrote:
I actually saw this in the newsgroups and thought it was a neat idea. What
about
println $textvar;
instead of
print "$textvar\n";
Ever so much easier to read and write, prints the arg and appends \n.
You can currently get
At 12:04 AM 8/7/00 +0200, Bart Lateur wrote:
On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote:
Even in perl5 an XS module can do _anything at all_.
It can't access data the lexer's already tossed out. That's where the
current format format (so to speak) runs you into trouble.
Only if
99 matches
Mail list logo
