On Tue, 29 Aug 2000, Nathan Wiger wrote:
> David Nicol and I were brainstorming offline, and came up with a cool
> extension: ~=. These new operator would do a similar thing to =~ as
> described by the RFC, only LEFT padding the args:
>
> $stuff =~ dojunk(@args); # $stuff = dojunk(@args, $s
> currently we can do
>
> $str = "foo bar";
> substr($str, 4, 0) = "baz ";
>
> and $str will become "foo baz bar". should we be able to do
> this with lvalue-subs? how can one returns "pointer" to a
> portion of a scalar?
sub partial: lvalue {
On Wed, Aug 30, 2000 at 02:26:08PM +0800, Kenneth Lee wrote:
> dear all,
>
> it seems all the "lvalue sub" RFCs haven't mentioned this.
> currently we can do
>
> $str = "foo bar";
> substr($str, 4, 0) = "baz ";
>
> and $str will become "foo baz bar". should we be able to do
> this with lva
dear all,
it seems all the "lvalue sub" RFCs haven't mentioned this.
currently we can do
$str = "foo bar";
substr($str, 4, 0) = "baz ";
and $str will become "foo baz bar". should we be able to do
this with lvalue-subs? how can one returns "pointer" to a
portion of a scalar?
kenneth
"David L. Nicol" <[EMAIL PROTECTED]> writes:
> John Porter wrote:
> >
> > we should also support recursive data structures,
> > as in some functional languages. E.g. (pseudocode):
> >
> > define foo as {
> > short a;
> > foo b; # exists at first only
At 07:39 PM 8/29/00 -0700, Dirk Myers wrote:
>Tonight, the role of "Peter Scott" will be read by Perl RFC Librarian :
>
> > =head1 DESCRIPTION
> >
> > In a scalar context, the result should remain the same as it is now. It is
> > very tempting to make the list context return be the I
> > altered
Matt Youell wrote:
>
> > mainstream OO languages go). It looks like Dog could be a type of String
> > subclass.
>
> That was my first thought as well. Besides, I'd rather type:
>
> my Dog $spot("Spot");
>
> Which says everything that needs to be said without any repetition, and it's
> fai
On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
> First greatly stylistic compatibilty. An inexperienced programmer would
> see:
> my Dog $spot = "Spot";
>
> And become confused. It's totally unintuitive (at least so far as other
> mainstream OO languages go). It looks like Do
> mainstream OO languages go). It looks like Dog could be a type of String
> subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
> As with the above, th
Peter Scott wrote:
>
> Some people have already suggested renaming them; RFC 30
> takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
> issue of $ARGV which already has a meaning :-( If we can solve that one
> then I'd just make all those filehandles scalars.
I've been t
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis
pered:
| > > The way tr/// works is that a 256-byte table is constructed at compile
| > > time that say for each input character what output character is
| >
| > Speaking of which, what's going to happen when there
This post attempts to consolidate and summarise my proposals which I hope
provides a platform for n-dim matrices/tensors. I have repeated parts of
earlier posts to avoid confusion--sorry for the redundancy. I've also fixed
some areas from earlier posts--hopefully the examples here are correct and
Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis
pered:
|
| > Would there be any interest in adding these two ideas to this RFC:
| >
| > 1) tr is not regex function, so it should be regularized to
| >
| >tr(SEARCH, REPLACE, MOD, STR)
|
| MOD should be last
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED]
m> whispered:
| >The // tend to confuse people and make them expect tr to operate as a
| >regular expression.
|
| So what? q/.../ is not a "regex function" either. These are all
| pick-you-own-quotes function. This ma
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:20 PM
Subject: RFC 172 (v1) Precompiled Perl scripts.
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> ($foo = $bar) =~ s/x/y/; will never make much sense to me.
TC> What about these, which are much the same thing in that they all
TC> use the lvaluability of assignment:
TC> chomp($line = );
TC> ($foo = $bar) += 10;
> On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > > $r->{{qw(a b c d e f g h)}}
> > > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
> >
> > $r->{a}{b}{c}{d}{e}{f}{g}{h}
> >
> > which is only one character longer than the proposal...
>
> Except in the case wh
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:19 PM
Subject: RFC 171 (v1) my Dog $spot should call a constructor implicitly
> my Dog $spot should call a constructor implicitly
>
>
> T
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
> > $r->{{qw(a b c d e f g h)}}
> > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
>
> $r->{a}{b}{c}{d}{e}{f}{g}{h}
>
> which is only one character longer than the proposal...
Except in the case where you don't have
- Original Message -
From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 29, 2000 10:06 PM
Subject: RFC 169 (v1) Proposed syntax for matrix element access and slicing.
> I propose the use of ';' as a separator for index te
> my Dog $spot = Dog->new();
>
> Provided this RFC is adopted, this call can be changed to:
>
> my Dog $spot = "Spot";
I like it, lots. This melds very well with RFC 159 and 161. Very cool.
> my Dog $spot = "Spot";
>
> would be transformed to, or be the equivalent of:
>
> $spo
Mark-Jason Dominus wrote:
>
> The IMPLEMENTATION section of the RFC is supposed to be mandatory, but
> there have been an awful lot of RFCs posted that have missing or
> evasive IMPLEMENTATION sections.
Well, I have to counter this with the following: Having a complete
IMPLEMENTATION section sho
Dan Sugalski <[EMAIL PROTECTED]> writes:
> On 29 Aug 2000, Russ Allbery wrote:
>> I'd love to see Perl aggressively take advantage of new capabilities in
>> dynamic loaders, though. Among other things, I'll point out that
>> symbol versioning is the way that things like libc manage to be
>> bac
>Simpify syntax of C by deleting C before the
>block and C<;> after it.
You can't do that. They do different things.
$n = do {
my $sum = 0;
for $i (@array) { $sum += $i }
$sum;
};
versus
$rec = {
FOO => 1.4,
BAR => "red",
};
--tom
>Having the
>indices in one place saves a lot of characters. Compare
>
> $r->{{qw(a b c d e f g h)}}
>
>versus
>
> $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h}
But I would compare it to
$r->{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
-
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Simplify C Syntax
=head1 VERSION
Maintainer: Mark Senn <[EMAIL PROTECTED]>
Date: 26 Aug 2000
Last-Modified: 29 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 167
Status: Developin
Nate asked me to look over this proposal and comment.
On a cursory reading, I have no objections to it, if the indirect
object syntax is to be preserved.
Damian
> >Still think C and C are cuter. :-)
>
> Except that that pair looks like "munge" and "emunge"...
Not to mention "mail" and "email" ;-)
Damian
(aka Multidimensional Arrays/Hashes)
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAI
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
subroutine / generic entity documentation
=head1 VERSION
Maintainer: Michael Maraist <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 176
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add C keyword to force list context (like C)
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 175
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Parse C as C
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 174
Status: Developing
=head1 ABSTRACT
Curre
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow multiple loop variables in foreach statements
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number:
Steve Fink wrote:
>
> Hm. Larry didn't really like anything that would reverse the order of
> the pattern and the expression to be matched against, and I think I
> agree at least that it should always be possible to put the direct
> object at the beginning, preferably in a way usable by more than
Tom Christiansen wrote:
>
> That's hardly the problem with indirect object syntax. Besides
> what I just mentioned, there is the fact that it's acting in a
> fashion that you could call stronger than a unary operator in terms
> of precedence.
This is also mentioned in the RFC, although probably
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Precompiled Perl scripts.
=head1 VERSION
Maintainer: Slava Pechenin <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 172
Status: Developing
=head1 ABSTRA
>Still think C and C are cuter. :-)
Except that that pair looks like "munge" and "emunge" (and probably
sounds like them too in certain accents :-), which are actually
synonyms of each other. :-(
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 1
> >I intend to extend the parameter lists RFC to cover optional
> >(non-trailing) arguments.
>
> Will this include having typed variadic functions, allowing you, for
> example, to say something like
>
> This function takes any number of arrays, all passed by reference.
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: 29 Aug 2000
Version: 2
Mail
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Generalize =~ to a special-purpose assignment operator
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 170
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposed syntax for matrix element access and slicing.
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 169
> This RFC proposes a simple use for C<=~>: as a last-argument rvalue
> duplicator. What this means is that an expression such as this:
>
>$value = dostuff($arg1, $arg2, $value);
>
> Could now be rewritten as:
>
>$value =~ dostuff($arg1, $arg2);
David Nicol and I were brainstorming off
> Builtins: merge() and demerge()
Still think C and C are cuter. :-)
And if we have to make up an antonym to C, let's choose C,
by analogy to C, C, C.
(And yes Tom, I *know* I'm advocating grafting a Germanic prefix to a
Latinate word and that "no good can come of it" ;-)
Damian
>What about these, which are much the same thing in that they all
>use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
>($foo = $bar) =~ s/x/y/; will never make much sense to me.
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
chomp($line = );
($foo = $bar) += 10;
($foo += 3) *= 2;
func($diddle_me = $protect_me);
$n = select($rout=$rin, $w
Tom Christiansen wrote:
>
> Perhaps you simply know inept C programmers.
Is there any other kind? ;-)
*Kidding*!
> In C, something that
> isn't declared auto or static is going to be global. Seeing no
> scoping declarations, the C programmer who knows C will come to the
> same conclusion as t
>Basically, it "fixes" the indirect notation by making all of these Do
>The Right Thing:
> $r = new CGI (@args); # CGI->new(@args)
> $r = new(CGI, @args); # CGI->new(@args)
> $r = new(CGI @args); # CGI->new(@args)
>It's all in the details (I'm sure you see the edge cases already, but
>
> > RFC138: Eliminate =~ operator.
>
> > RFC164: Replace =~, !~, m//, and s/// with match() and subst()
>
> Which I could see unifying. I'd ask people to wait until v2 of RFC 164
> comes up. It may well include everything from RFC 138 already.
Hm. Larry didn't really like anything that would re
Damian Conway wrote:
>
> I intend to extend the parameter lists RFC to cover optional
> (non-tailing) arguments. Personally, I would like to see the
> indirect object syntax removed in all contexts, inclusing
> this one, and filehandles simply passed as a first argument.
Whoa there! :-)
Not nec
>For the first part, tchrist posted a nice list of non-overridable
>builtins; running my eye down it, it looks like the gross offenders
>here are:
> glob, print, printf
>I don't know whether this is purely an implementation issue (and so
>lies solely in the domain of perl6-internals) or wh
>I intend to extend the parameter lists RFC to cover optional
>(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
I keep thinking of a * or a ... to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow exception-based error-reporting.
=head1 VERSION
Maintainer: Bennett Todd <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number:
>How about ALLOWING bareword everything-else? Start having
>filehandles work the way everyone expects them to at first,
>passing as arguments and so forth, without any special treatment?
One could do that, too. Or allow scoped declarations of
unadorned identifiers: this might be the road out o
>$x and $y are in the same scope. This is good, but also bad. For one
>thing, you can hang yourself real easily if you come from a C background
>and expect this to keep stuff private:
> $x = 10;
> sub square {
> ($x) = @_;
> $x *= $x;
> }
> $ans = square($x);
> print "$x squar
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Damian
On 29 Aug 2000, Russ Allbery wrote:
> I'm not sure I'm completely following what you're arguing for here, but be
> careful not to go too far down the road of duplicating what the dynamic
> loader already knows how to do. There be dragons; that stuff is seriously
> baroque. You really don't want
How about ALLOWING bareword everything-else? Start having
filehandles work the way everyone expects them to at first,
passing as arguments and so forth, without any special treatment?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Subroutine one-arg, him c
On Tue, 29 Aug 2000 19:06:24 -0600, Tom Christiansen wrote:
>>I feel that this ought to have worked, i.e. that the scope of the
>>lexical kicked in in the middle of the expression, at the transition
>>over the shortcut operator "&&".
>
>Except that then you can't say
>
>local $x = $x;
>or
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins: merge() and demerge()
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Last modified: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: part
=head1 VERSION
Maintainer: Jeremy Howard <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 91
Status: Deve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
New pragma 'scope' to change Perl's default scoping
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 07 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version
>
> I am lazy. I am spoiled by the implicit $_. I like the implicit
> $_. Implicit $_ good. Ugh. (Conversely, some people abhor the
I believe you mean "Ug." "Ug" means you are speaking pidgin, while
"Ugh" indicates disgust.
> =head1 IMPLEMENTATION
>
> The front-end would have to detect v
Boy, there are a lot of people on that CC: list... Anyone want off
this ride?
Jeremy Howard said:
> This RFC is a good start. Here's some thoughts on ways to decrease the
> amount of new syntax and avoid the HOF ambiguity... Also, I suggest multiple
> RFCs for the different ideas contained with
One function that takes an optional leading commaless arg:
sub print(handle? $FH, @)
or
Two functions differentiated by their prototypes
sub print(@);
sub print(handle,@);
I'm always forgetting the comma after the handlename in
C statements because I learned "no c
>>sub getfh {
>> return open(my $fh, "+< /dev/null") && $fh;
>>}
>Aha! You fell for one of my pet pieves. You tried to return a lexical in
>the same expression were it was declared. That doesn't work. It's not
>the same variable. Running it with warnings enabled says:
Grr..
> Na
> > The way tr/// works is that a 256-byte table is constructed at compile
> > time that say for each input character what output character is
>
> Speaking of which, what's going to happen when there are more than 256
> values to map?
It's already happened, but I forget the details.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
N
On 29 Aug 2000, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > It's not unreasonable to expect this sort of feature to possibly be used
> > for more esoteric extensions to the perl core or commonly and heavily
> > used extensions. I wouldn't, for example, want to always loa
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Implicit
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Richard Proctor wrote:
>
> This leads back to my original "remove all whitespace". Somehow there is a
> compromise to extracted from this.
Have we explored using a subset of regex for end-markers?
$long_string_possibly_indented_later = <<\w*##ENDEND##\w*;
.
On Tue, 29 Aug 2000 20:36:46 -0400, Bryan C.Warnock wrote:
>> The way tr/// works is that a 256-byte table is constructed at compile
>> time that say for each input character what output character is
>
>Speaking of which, what's going to happen when there are more than 256
>values to map?
A bigg
On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote:
>You could pass it as
>
>p(*FH);
>
>instead, and the function's definition doesn't change.
Typeglobs are on the endangered species list. That is part of the reason
for this RFC.
>sub getfh {
> return open(my $fh, "+< /de
David L Nicol <[EMAIL PROTECTED]> writes:
> This is what I was talking about when I suggested the language maintain
> a big list of all the addresses of each function, and after the function
> gets loaded or compiled it is added to the big list, and after this
> stage the placeholder in the op ca
Dan Sugalski <[EMAIL PROTECTED]> writes:
> It's not unreasonable to expect this sort of feature to possibly be used
> for more esoteric extensions to the perl core or commonly and heavily
> used extensions. I wouldn't, for example, want to always load in
> DBD::Oracle or a full complex math libra
On Tue, 29 Aug 2000, Mark-Jason Dominus wrote:
> I think the reason this hasn't been done before it because it's *not*
> quite straightforward.
>
> The way tr/// works is that a 256-byte table is constructed at compile
> time that say for each input character what output character is
Speaking of
At 06:17 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Eliminate bareword filehandles.
>
>"Eliminate" is such a strong word. You're saying that we can't
>use STDIN, STDOUT, STDERR, ARGV, or DATA anymore?
There are some people I would like to stop using output filehandles, yes :-)
> Heck, some
>Tom Christiansen wrote:
>>
>> >Eliminate bareword filehandles.
>>
>> "Eliminate" is such a strong word. You're saying that we can't
>> use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
>> still use stdin and stdout! :-)
>Disclaimer: I am not attempting to put words in anyone
Dan Sugalski wrote:
> On Wed, 30 Aug 2000, Jeremy Howard wrote:
> > Furthermore, if it has a single basic data type and is declared
':compact'
> > it should be stored in a contiguous block of memory.
>
> If you do a plain
>
> my int @foo;
>
> it'll end up with a contiguous block of memory anyway
Tom Christiansen wrote:
>
> >Eliminate bareword filehandles.
>
> "Eliminate" is such a strong word. You're saying that we can't
> use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
> still use stdin and stdout! :-)
Disclaimer: I am not attempting to put words in anyone's mouth
Perl6 RFC Librarian wrote:
> With the enhanced C operator, subroutines can dynamically decide
> what to return.
With context-based polymorphism, the decision can be made staticly.
>Tom Christiansen wrote:
>>
>> If you can no longer grow hashes or arrays on demand, does this
>> extend to strings not being able to get bigger, and to integers not
>> being able to become floats?
>>
>> --tom
>Exactly. What do you think :closed should do, Tom?
Something more like old :ronly
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>=head1 TITLE
>Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
still use stdin and stdout! :-)
>=hea
On 29 Aug 2000, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > 2) Having a mechanism to automagically load in chunks of executable code
> > only when needed would be nice
>
> It's not clear to me how useful this really is from an internals speed
> standpoint on modern syst
Tom Christiansen wrote:
>
> If you can no longer grow hashes or arrays on demand, does this
> extend to strings not being able to get bigger, and to integers not
> being able to become floats?
>
> --tom
Exactly. What do you think :closed should do, Tom?
--
David Ni
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate the optional C for C etc block declarations
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Versio
>>> > * Using an array of "words" as an alternate list as part of a regex
>>> /match any of (${\join'|',@list}) here/
>NT> $" = "|"; /@list/ # snicker
Certainly I've written
if (do { local $" = "|"; $var =~ /@any/}) { blah() }
before.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C<||> and C<&&> should propagate result context to both sides
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 29 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED
On Wed, 30 Aug 2000, Jeremy Howard wrote:
> Karl Glazebrook wrote:
> > Dan Sugalski wrote:
> >
> > > On the other hand, just extending out arrays to be multidimensional may
> > > well be good enough.
> > >
> >
> > This is my view.
> >
> Ditto. As I said yesterday, my current preferred option is t
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> : This can be very hard to discover. I find it hard to see myself doing
LW> : this on purpose. I would like to see a compiler warning for this:
LW> : "Spaces detected after apparent here document terminator", but
LW> : preferably phrased b
Dan Sugalski <[EMAIL PROTECTED]> writes:
> 2) Having a mechanism to automagically load in chunks of executable code
> only when needed would be nice
It's not clear to me how useful this really is from an internals speed
standpoint on modern systems. It's no longer always true that increasing
th
On Wed, 30 Aug 2000, Jeremy Howard wrote:
> I think as long as we specify the features we need in our language RFCs, the
> internals folks will identify the common threads needed to implement them.
> This means that we should ensure that efficiency goals should be spelled out
> in each RFC where
Dan Sugalski wrote:
>
> Don't forget the fixup work that needs to be done afterwards. Loading the
> library into memory's only the first part--after that the loader needs to
> twiddle with transfer vectors and such so the unresolved calls into the
> routines in the newly loaded library get resol
On Wed, 30 Aug 2000, Christian Soeller wrote:
> A second related question: would I be able to return a list of arrays
> from a function, e.g.
>
> (@fit,@corr) = fitit @x, @y;
>
> How could I find out if the user wants just one array or two?
If this feature goes in, there'll be some sort of w
> One often heard argument is that subroutines like these must be
> callable in either mode:
>
> lvsub(expr)
> lvsub() = expr
>
> This argument is false, since the two uses are totally distinct.
Yes and no. It depends on your application.
I'm not shooting down the RFC at all, but this
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> > * Using an array of "words" as an alternate list as part of a regex
>> /match any of (${\join'|',@list}) here/
NT> $" = "|"; /@list/ # snicker
Is $" one of the specials scheduled for the axe?
--
Chaim Frenkel
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Named operators versus functions
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last Modified: 28 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 26
1 - 100 of 315 matches
Mail list logo
