On Wed, 20 Sep 2000, Bart Lateur wrote:
> The argument against my reasoning would be if the bulk of people making
> this mistake are *not* coming from C. I don't know.
I have a feeling we're either arguing the same side without
realizing it, or we're just having a straight-up conversati
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 20 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 39
Version: 4
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in for statements, possibly $#.
=head1 VERSION
Maintainer: John McNamara <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Improved parsing and flexibility of indirect object syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED
In message <2920001558$[EMAIL PROTECTED]>
Garrett Goebel <[EMAIL PROTECTED]> wrote:
> I'm particularly interested in commentary for and against:
> - the proposal as a whole
I think there's a big difference between the sort of short
circuiting provided by RFC 199 which I feel is bes
In <12839.969393548@chthon>, Tom Christiansen writes:
:What can be done to make $ work "better", so we don't have to
:make people use /foo\z/ to mean /foo$/? They'll keep writing
:the $ for things that probably oughtn't abide optional newlines.
:
:Remember that /$/ really means /(?=\n?\z)/. And l
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> =head1 TITLE
>
> Add null() keyword and fundamental data type
>
> =head1 MIGRATION
>
> None. New functionality.
Not true. Apart from the discussion if undef is the same as null, in which I
take no stance, Migration
On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote:
>undef null
>
>$a = undef; $a = null;
>$b = 1; $b = 1;
>$c = $a + b; $c = $a + $b;
>
>$c is 1
On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote:
> Perl already has exactly the data value that you're looking for. This RFC
> is proposing to fix the wrong problem; the things that need to be changed
> (conditionally) are the logical operators, not the data value.
Absolutley, altho
On Wed, Sep 20, 2000 at 05:08:26AM -, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
>
> This RFC proposes a built-in C function, modelled after Graham
> Barr's C subroutine from the List::Utils module (a.k.a. The
> Module Formerly Known As builtin.pm).
:-)
> If fewer than N-1 elements would
On Tue, 19 Sep 2000 07:40:07 -0700 (PDT), Dave Storrs wrote:
>> Doesn't this reflect C's idea of "a string is an array of characters"?
>> Which isn't the idea behind strings in Perl. The basic idea is wrong.
>> Therefore, making length(@array) work, would be a wrong signal.
>
> I personally
On Mon, 18 Sep 2000 11:42:50 -0400, Chris Nandor wrote:
>>But the OS's idea of the epoch is global!
>
>No, it isn't! On Mac OS, I can change my epoch by changing my time zone.
>If it is harcoded into Config.pm, I am fucked.
This is bad. That system is broken. ;-) I guess that it's the same
situ
At 13:23 +0200 2000.09.20, Bart Lateur wrote:
>This surely was a bad design decision from the hardware guys. Very
>shortsighted.
I don't know if it has anything to do with the hardware clock. It has to
do with what the Mac OS API returns for seconds since epoch. The
difference from GMT, or the
On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
> Graham Barr Wrote:
> >Well if there ever is a way to shortcut grep this could be genera;ized
> >to
> >
> > my $index = grep { break if $_ eq $seek; 1 } @items;
>
> Wouldn't this also assume that grep return the number of times the bloc
> >undef null
> >
> >$a = undef; $a = null;
> >$b = 1; $b = 1;
> >$c = $a + b; $c = $a + $b;
> >
> >$c is 1 $c is null
I'm quite sure that
David Nicol Wrote in RFC 262:
>foreach $item (@items){
>#print "$item was at location ",$item:n,"\n";
>print "$item was at location ${item:n}\n";
>};
What would really be nice here is an C function, similar to the
scalar version, that returns the index of the matching entry in a list. For
instanc
On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
> David Nicol Wrote in RFC 262:
> >foreach $item (@items){
> >#print "$item was at location ",$item:n,"\n";
> >print "$item was at location ${item:n}\n";
> >};
>
> What would really be nice here is an C function, similar to the
> scalar v
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
2. In your abstract, you say that undef is used to mean that a
variable's value is undefined, which I presume means uninitialized.
You say that null would provide a useful way to i
Graham Barr Wrote:
>Well if there ever is a way to shortcut grep this could be genera;ized
>to
>
> my $index = grep { break if $_ eq $seek; 1 } @items;
Wouldn't this also assume that grep return the number of times the block was
NOT true, rather than it's current implementation of the number of
Tom Hughes <[EMAIL PROTECTED]> writes:
>
>What I'd like to see us avoid is the current situation where trying
>to examine the value of an SV in the debugger is all but impossible
>for anybody other than a minor god.
What is so hard about:
gdb> call Perl_sv_dump(sv)
???
>
>Tom
--
Nick Ing-Sim
>What I said was: making length(@array) "work" would be catering to
>novice people *coming from C*. We shouldn't. Not that much. In Perl, a
>string is not an array.
I'm pretty sure it's not just the people coming from C who expect this.
This all points to the bug^H^H^Hdubious feature which is th
On Wed, Sep 20, 2000 at 04:15:13AM -, Perl6 RFC Librarian wrote:
> =head2 The Basics
>
> The new C pragma would rely on an C file that
> was located in C<@INC> and looked something like this:
What happens when there are multiple C files in C<@INC>?
> A custom one could also be included in C
This will make programs highly nonportable. You can't easily know what
modules they really need.
--tom
On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >> (SE), AFAIK, and therefore the man pages should be an option that could be
> >> deleted to save space.
>
> >This is already an option, and has been for years. I don't imagine that
> >would change in perl6.
>
> I should much prefer to see random
I talked with Larry about schedule. I'd been under the impression he
was going to produce a draft language spec on October 1, and the final
on October 14. He set me straight: draft on October 14 (his keynote
to the Atlanta Linux Showcase), no deadline yet for final spec.
So we have until Octobe
Nathan Wiger wrote:
>
>undef null
>
>$a = undef; $a = null;
>$b = 1; $b = 1;
>$c = $a + b; $c = $a + $b;
>$c is 1 $c is null
Uh, this is a
On Tue, 19 Sep 2000, Tom Christiansen wrote:
> >This RFC proposes that the internal cursor iterated by the C function
> >be stored in the pad of the block containing the C, rather than
> >being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when
> If you want different semantics for undef then use a pragma, that is
> what pragmas are for.
> However I would suggest that many, including myself, would not like
> to see perls values have yet another state of null
Here's my concern about changing the meaning of undef. Convince me this
is not
On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> Using the proposed tristate pragma does not strike me as any better -
> in fact, worse - than adding null() because you are now changing the
> meaning of fundamental Perl operations. You're *still* introducing "yet
> another state of
On Wed, Sep 20, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> This is just as dangerous as having a pragma like so:
>
>use 'zeroistrue';
>$num = 0;
>print "Got data" if ( ! $num );
>
> Where the above would print out "Got data" normally, but not under
> the pragma.
Yep, this is ba
Graham Barr wrote:
>
> But what does it do if the block
> is a curried function of three arguments, but the list only contains two ?
Return a curried function of one argument, of course.
At least, that's what it *should* do...
--
John Porter
iain truskett wrote:
>
> Return a specified value (such as 'undef'). It would allow for more
> elegant code, I think. The universe is old enough to cope by itself.
When I first read this, I thought it said:
The universe is old enough to copy itself.
!-)
--
John Porter
Nathan Wiger wrote:
>
> Since undef() has established semantics, I don't think these should
> change. I believe taking from RDBMS and adding null() which has the
> correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different "special non-value"
semantics
Tom Christiansen wrote:
>
> You want to have more properties that work like tainting does: a
> per-SV attribute that is enabled or disabled by particular sorts
> of expressions, sometimes dependent upon the previous presence or
> absence of that property, other times, not so.
While we're at it,
I'm not sure where CORBA fits into the picture, frankly, it will probably never impact
my niche, which is dumb-ass operation$.
But one of the contractors here is thinking about switching to python to get the CORBA
implementation, he claims perl is not serious in that
direction.
The only reas
From: John van V [mailto:[EMAIL PROTECTED]]
>
> I'm not sure where CORBA fits into the picture
I doubt it fits in the internals...
> But one of the contractors here is thinking about switching
> to python to get the CORBA implementation, he claims perl is
> not serious in that direction.
We
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> Wait. I see now: you've asked us to endorse murdering children in
TC> their sleep. Same answer: I won't do it because it's evil and
TC> wrong. I am vehemently and vociferously opposed to software that
TC> is installed *ANYWHERE* wi
Today around 1:36pm, Chaim Frenkel hammered out this masterpiece:
: > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
:
: TC> Wait. I see now: you've asked us to endorse murdering children in
: TC> their sleep. Same answer: I won't do it because it's evil and
: TC> wrong. I am veheme
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Could you explain what the problem is?
TC> /$/ does not only match at the end of the string.
TC> It also matches one character fewer. This makes
TC> code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
$_ = "etc\n";
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>>> Could you explain what the problem is?
>TC> /$/ does not only match at the end of the string.
>TC> It also matches one character fewer. This makes
>TC> code like $path =~ /etc$/ "wrong".
>Sorry, I'm missing it.
I know.
On your
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interface polymorphism considered lovely
=head1 VERSION
Maintainer: Piers Cawley <[EMAIL PROTECTED]>
Date: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 265
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 7 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTEC
I didn't see any mention of my plea that C should pass the
original variable being tied as one of its arguments. :-(
E.g.:
sub ReadOnly::TIESCALAR {
my ($class, $original, @otherargs) = @_;
bless {
internals => \@otherargs,
Damian Conway wrote:
>
> I didn't see any mention of my plea that C should pass the
> original variable being tied as one of its arguments. :-(
That's because it's a dumb idea!!
**Kidding!**
I forgot about this, sorry. I'll add it to the next version ;-)
> my $x = 10;
> ti
On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote:
>> Read RFC 241 for a brief overview of pseudo-hash problems.
>
>I've already read RFC 241. Re-reading in this context results in the following
>comments/quests for information. The remaining quotes here come from RFC 241...
>
>>
>I wonder if this problem couldn't be solved with a proper combination of
>@ISA, SUPER::, NEXT::, and use delegation? (calling Damian... :-)
The problem I see is a bit of trickery would be necessary to get
static calls to the class to resolve to the appropriate method.
Using Schwern's DBI examp
>The DBI has this very problem! DBI->connect() returns DBI::db
>objects, DBI->prepare() returns DBI::st. If you want to override the
>behavior for statement handles and connections, its not enough to just
>subclass DBI::st and DBI::db, you must also subclass DBI and override
>connect() and prepa
I haven't (and won't) have time to go into this in detail :-(
I feel that this proposal is solving the wrong problem. The issue is
that the original Forest and Frog (or DBI and DBI::st) classes are not
*designed* for user-definable Frogs (DBI::st's). If that functionality
is widely needed, the Fo
On Wed, 20 Sep 2000 07:03:33 -0600, Tom Christiansen wrote:
>I'm pretty sure it's not just the people coming from C who expect this.
Uh-oh.
>This all points to the bug^H^H^Hdubious feature which is the sub($)
>context template as applied to named arrays and hashes. Requiring
>an explicit conve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 18 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 132
Today around 1:03pm, Tom Christiansen hammered out this masterpiece:
: Perl has *one* out-of-band value. It doesn't need more. That
: doesn't mean that perhaps some rare sorts of programming might not
: benefit from fancy weirdnesses. That's what modules are for.
: You don't need to complicate
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
> iain wrote:
> > * Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
> > > > no strict;
> > > > $a = undef;
> > > > $b = null;
> > > Perl already has a null string: "".
> > Looks more like a string of no length than
Eric Roode wrote:
> Glenn Linderman wrote:
> >Eric Roode wrote:
> >
> >> 1. You don't say in your RFC, but I'm guessing, that a null value
> >> evaluates to false in a boolean context. Correct?
> >
> >I would expect it to be considered false. Logical expressions involving
> >NULL are defined to
Tom Christiansen wrote:
> > no strict;
> > $a = undef;
> > $b = null;
>
> Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted. NULL is neither number nor st
Tom Christiansen wrote:
> Perl has *one* out-of-band value. It doesn't need more. That
> doesn't mean that perhaps some rare sorts of programming might not
> benefit from fancy weirdnesses. That's what modules are for.
> You don't need to complicate the general language to get what
> you want.
>It only takes a few pages, and a few truth tables to explain NULL.
>It should only take a few pages and a few examples, to explain the
>difference between undef and null.
Ah, so the cost of this is twice a few pages of explanation, plus truth
tables and examples? Are you mad?
I can think of n
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
> >It only takes a few pages, and a few truth tables to explain NULL.
> >It should only take a few pages and a few examples, to explain the
> >difference between undef and null.
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 3
Status: Deve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 4
Status: Froze
> Some of oriental characters in Japanese and Korean are usually
> aligned as if they have 2 columns per character.
>
> Japanese has another formatting rule that punctuation characters
> cannot appear at the beginning of or end of line (depending on
> their meanings).
The pro
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
linkable output mode
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 121
Version: 2
Status: Fro
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 168
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins : Make use of hashref context for garrulous builtins
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Last Updated: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
>* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
>> > no strict;
>> > $a = undef;
>> > $b = null;
>> Perl already has a null string: "".
>Looks more like a string of no length than a null string.
Well, it's not. That's a null string. You're thinking of "\0",
a true va
Nathan Wiger <[EMAIL PROTECTED]> writes:
> undef has a very well-defined (ha!) Perl meaning: that something is
> undefined. null has a very well-defined RDBMS meaning: that something is
> unknown. Perl allows you to add and concatenate stuff to undef, because
> that value can be coerced into 0 an
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> Yep, this is bad IMHO. Your concern is valid I think, but your
> "solution" isn't a good one. Why not just use a module like Damian's
> Quantum::Superpositions?
No offense to Damian, but I tried to read and understand his documentation
and I th
Glenn Linderman <[EMAIL PROTECTED]> writes:
> With the multitudinous operator approach, please show me how to make
> each of the following conditional statements print true, without
> cluttering the code with interleaved additional pragmas and scoping
> blocks. Use of pragmas before the code mig
Glenn Linderman <[EMAIL PROTECTED]> writes:
> undef has the following semantics:
> 1) all otherwise uninitialized variables are set to undef
And as the RFC says, quite a few times, for database code you often want
all your variables to start as the null value.
> 2) under "use strict", use of u
Tom Christiansen <[EMAIL PROTECTED]> writes:
>>$a = null;
>>$b = ($a == 42);
>>print defined($b)? "defined" : "not defined";
>> would print "not defined", maybe?
> In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
> only 1 or "". Both are defined.
But if you
>That's not much different than the cost of undef, so I fear it proves
>nothing, universally.
YOU OVERQUOTEDsen wrote:
YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and nu
>> For example, assuming this code:
>>$name = undef;
>>print "Hello world!" if ($name eq undef);
>So don't do that. Use C if you want to ask that question.
That's why I want to change the names of these things. The current
situation invites errors such as seen previously.
Actually,
>Tom Christiansen wrote:
>> > no strict;
>> > $a = undef;
>> > $b = null;
>>
>> Perl already has a null string: "".
>That's an empty string. In any case, if you really want to call it a
>null string, that's fine, just a little more likely to be
>misinterpreted.
In Perl, this is t
Perl6 RFC Librarian wrote:
[...]
> =head1 TITLE
>
> All perl generated errors should have a unique identifier
>
[...]
> An id string could have some structure associated to enable
> better handling. One suggestion was to follow the lead of VMS.
>
> facility:
> The program
>> I'm not happy with your use of "coerce". There's no mutation. It simply
>> *is* those things.
>Fine. So, in particular, it _isn't_ null.
Of course it's null. That's why it has length zero. Stop speaking
SQL at me. I'm speaking Perl.
>> 4) The antiïinitialized value is autovivified to a
Tom Christiansen wrote:
>
> By your "reasoning", we can just add infinitely more things that
> take twice a few pages to explain.
>
> Perl is already too hard.
Yes, it is.
And that's why I'm against C.
(Had to get that plug in there) ;-)
-Nate
* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> > Yep, this is bad IMHO. Your concern is valid I think, but your
> > "solution" isn't a good one. Why not just use a module like
> > Damian's Quantum::Superpositions?
> No offense to Dam
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
> "VARIABLE used only once: possible typo" should be replaced with
> warnings on uses of uninitialized variables (including lexicals).
> $x = 3
I don't understand, who's to say you didn't misspell $x? If you're only
using it
On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
> > I think that this is better done as a special overloaded object used
> > by database modules which wish to implement SQL-style tri-state logic.
>
> It could be done as an overloaded object. You'd have to be able to overload all
Glenn Linderman wrote:
> Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
In message <[EMAIL PROTECTED]>
Dave Storrs <[EMAIL PROTECTED]> wrote:
> This runs into problems if you currently have an iterator extant and you
> modify the hash to which it points. Immediate suggestions on how to
> handle this would be:
>
> 1) Do what the docs currently do; tel
On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
> No offense to Damian, but I tried to read and understand his documentation
> and I thought I was back in grad school. I don't think it's the fault of
> the writing either; I think that Quantum::Superpositions is trying to do
> someth
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>>> Currently many programs handle error returns by examining the text of
>>> the error returned in $@. This makes changes in the text of the error
>>> message, an issue for the backwards compatibility police.
>TC> eval { fn() };
>
Bart Lateur <[EMAIL PROTECTED]> writes:
> This is bad. That system is broken. ;-) I guess that it's the same
> situation on MS-DOS, since there the hardware clock is usually set to
> local time. It could even happen on Win32?!?
> This surely was a bad design decision from the hardware guys. Very
On 20 Sep 2000 13:03:22 -0700, Russ Allbery wrote:
>It's not a hardware problem; the hardware clock just keeps a time. It has
>no concept of time zones.
I thought later on that I wrote this the wrong way. What I ment was: the
guys who did the interface to the hardware.
>It's a software problem
From: Chaim Frenkel [mailto:[EMAIL PROTECTED]]
>
> From: Tom Christiansen <[EMAIL PROTECTED]>
> >
> > Same answer: I won't do it because it's evil and
> > wrong. I am vehemently and vociferously opposed to software that
> > is installed *ANYWHERE* without documentation. If there is no
> > docum
Thanks for getting this RFC together, Piers.
A few comments:
* I suggest you remove my alternative C<:must(Foo)> suggestion.
It's too ugly to live, inless you just want to use it as a
scare tactic to encourage Larry to chose the C
syntax instead ;-)
> I have a pretty primitive idea in my head: suppose a Taxi object has
> multiple inheritance, it inherits from both a Car and a Driver... So a
> Taxi is both a Car and a Driver. But shouldn't you also make this that a
> Taxi is a Car that also *contains* a Driver, instead of *being* o
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 110
Version: 6
Status: Fro
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Varibles in tr///
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 27 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 166
Version: 3
Stat
Tom Christiansen wrote:
> Don't forget /s's other meaning.
Do you enjoy making people ask what you're talking about? What other
meaning did you have in mind, overriding $*?
--
Robert Mathews
Software Engineer
Excite@Home
>Tom Christiansen wrote:
>> Don't forget /s's other meaning.
>Do you enjoy making people ask what you're talking about?
Of course not. I enjoy giving people enough pointers to help them
learn things for themselves.
>What other
>meaning did you have in mind, overriding $*?
Yes.
--tom
perl6-language-regex
Summary report 2920
Mark-Jason Dominus has relinquished the wg chair due to the pressure
of other commitments; I'll be taking over the chair for the short
time remaining. Thanks to Mark-Jason for all his hard work.
I'll be contacting the authors of all outsta
On Wed, 20 Sep 2000 10:03:08 +0100, Hugo wrote:
>In <12839.969393548@chthon>, Tom Christiansen writes:
>:What can be done to make $ work "better", so we don't have to
>:make people use /foo\z/ to mean /foo$/? They'll keep writing
>:the $ for things that probably oughtn't abide optional newlines.
>That was my second thought. I kinda like it, because //s would have two
>effects:
> + let . match a newline too (current)
> + let /$/ NOT accept a trailing newline (new)
Don't forget /s's other meaning.
--tom
On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
>Where an array is declared without ':bounds', @# returns the largest
>bounds of each dimension that has been accessed:
Wouldn't that be slow?
--
Bart.
Buddha Buck wrote:
> On RFC 204 (LOL refs as indices), I have followed the discussion from
> Ilya that list references will have problems when objects that used
> blessed references to lists as their internal representation are used
> as indices. This does indeed seem to be a problem, but I'm unc
Bart Lateur wrote:
> On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
>
> >Where an array is declared without ':bounds', @# returns the largest
> >bounds of each dimension that has been accessed:
>
> Wouldn't that be slow?
>
It depends. The array creation RFC proposes that LOLs declared w
Perl6 RFCs: Overdue RFCs
Report generated: Wed Sep 20 21:40:38 2000 GMT
265 RFCs submitted.
189 RFCs in development.
126 RFCs not updated within the last 7 days.
perl6-language: 56 RFCs overdue
perl6-internals: 18 RFCs overdue
perl6-language-data: 10 RFCs overdue
perl6-language-flow: 8
> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes:
Bart> So length is already picky on what it accepts. You need to turn it into
Bart> print length(scalar(@a, 'this is a string'));
Bart> to get perl to accept it.
And then what it's accepting is the scalar-comma operator, giving you
the
> "CRT" == Casey R Tweten <[EMAIL PROTECTED]> writes:
CRT> rm them.
Sure, and I can sling around the manpages after they have been installed
in the wrong place. I can also run all of the make files by hand.
If I can go in and simply comment out the INSTALL section of the makefile
(which I h
1 - 100 of 173 matches
Mail list logo
