Graham Barr wrote:
>Maybe not with 3 variables, but how many people do
>
> my %hash = @_;
> { ... }
>
>so that they can process named arguments ?
>
>Having this would remove the need for the hash assignment. Also it hash been
>suggested that it could potentially replace each
>
> { ... }
I'm n
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > Basically, I want to be able to create a list ref of list refs, specify
a
> > data type (eg 'int') and attributes of ':compact' or ':sparse', and have
the
>
> As Dan Sugalski suggested it seems not a good idea to bring in the list
> of list ref
>Now, every error is guaranteed to be an object. You can call some method
>or check some attribute of it to find out if it was an exception. If
>you're checking a system() or `` failure, you use it in numerical
>context. If you're checking a builtin failure, you use it in string
>context (u
At 13:11 28/08/00 -0400, Steve Simmons wrote:
>To tell the truth, this third item should probably should become
>a separate RFC, and if you'd like to simply say one is forthcoming,
>that'd be fine by me.
What I really want to do is write a summary, get some consensus and redraft
the RFC. I'll do
Lightning flashed, thunder crashed and Michael G Schwern <[EMAIL PROTECTED]> wh
ispered:
| On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote:
| > The C and C commands are legacy commands which have been
| > deprecated for at least 5 years. They should be removed from the languag
[EMAIL PROTECTED] wrote:
> DO NOT fill -language with discussions of pseudo-RFCs. Please.
> I'm begging you.
>
> K.
Then where is the proper forum for mere ideas, non focused enough to
formalize into an Official Proposal?
Or do you just mean those particular ones.
--
Nathan Wigner in the guise of Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> You can use facilities such as C to help fix this issue, but
> C is limited and slow. You can also overload operators, but
> this is not flexible enough for many applications since it applies
> to a package (and not in
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: Aug 18, 2000
Last Modified: Aug 28, 2000
Version: 3
Mailing List: [EMAIL PROTECTED
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
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
> 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
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 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
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
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
>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
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
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
> >Still think C and C are cuter. :-)
>
> Except that that pair looks like "munge" and "emunge"...
Not to mention "mail" and "email" ;-)
Damian
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
Then you are back to locking everything in sight.
Consider the simple solution.
my $group_a : shared;
my $group_b : shared;
sub foo { lock $group_a; }
sub fo1 { lock $group_a; }
sub fo2 { lock $group_a; }
sub bar { lock $group_b; }
s
--On 29.08.2000 12:15 Uhr -0400 Chaim Frenkel wrote:
>
> But the grouping of related locks can most easily be done by the user
> and probably a lot more efficiently then the pessimistic locking perl
> would need to perform.
I completely agree. The only thing I'd have to add is that the lock co
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
> At 13:11 28/08/00 -0400, Steve Simmons wrote:
> >To tell the truth, this third item should probably should become
> >a separate RFC, and if you'd like to simply say one is forthcoming,
> >that'd be fine by me.
>
> What I really want
At 09:41 PM 8/28/00 -0600, Tony Olekshy wrote:
>I just want the cognitive simplicity of knowing that $@ and every
>@@ isa Exception, no matter what.
>
>Why not merge $!, $^E, and $@ into $!, but leave $@ alone too?
>That way, none of the existing die/eval code will break without
>being modified to
At 06:05 PM 8/29/00 +, Jim Edwards wrote:
>IMHO if the perl6 core only allow access to the parser, than a module can
>do just about anything including all of those things proposed in RFC 115 - 117.
That's sort of on the list of things to allow (I think Damian RFC'd it) but
whether it happe
>
>
> Regardless, you can already do this in perl 5, and will undoubtedly be able
> to do it in perl 6, with source filters.
So why do we have to do
$ip1=$i+1;# my pdl pet peave
$f->slice("(0),$ip1,$i");
instead of
$f((0),$i+1,$i); # substitute your favorite syntax
At 06:21 PM 8/29/00 +, Jim Edwards wrote:
> >
> >
> > Regardless, you can already do this in perl 5, and will undoubtedly be able
> > to do it in perl 6, with source filters.
>
>So why do we have to do
>$ip1=$i+1;# my pdl pet peave
>$f->slice("(0),$ip1,$i");
>
>instead
> "CS" == Christian Soeller <[EMAIL PROTECTED]> writes:
CS> The other problem with arrays is: how do we deal with functions that
CS> take multiple piddle arguments if they are arrays:
CS>@result = integrate @x, @y, @bounds;
CS> Won't those all be clumped into one big input array? Does i
Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
Isn't reshaping the basic operation of interest?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
At 12:42 PM 8/29/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
> >
> > At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
> >
> > >But scalars are not compact.
> >
> > Since scalars are singular things, how would you compact them anyway?
> >
>
>If I say $a = ones(float,10,10) in PDL then ea
At 12:43 PM 8/29/00 -0400, Karl Glazebrook wrote:
>Dan Sugalski wrote:
>
> > >It would be bad to have multiple RFCs suggesting the same thing.
> >
> > Nope, it wouldn't be.
> >
> > Don't assume that any particular RFC will be accepted in its entirety
> > either--it's always possible that Larry'll
At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:
>You should have a look at the PDL RFC 117 before submitting this.
>
>It would be bad to have multiple RFCs suggesting the same thing.
I just read PDL RFC 117, and your current argument with Dan aside...
I don't see a problem.
Here is the core
IMHO if the perl6 core only allow access to the parser, than a module can do just
about anything including all of those things proposed in RFC 115 - 117.
Maybe this is an over simplification, but it seems that if the statement:
use Python;
caused the subsequent source to go through my Python:
>Well then. It is impossible to rearchitect it to make it shared
>text? Perhaps the first instance of perl sets up some vast shared
>memory segments and a way for the newcomers to link in to it and look
>at the modules that have been loaded, somewhere on this system, and use
>the common copy?
I
At 12:02 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Well then. It is impossible to rearchitect it to make it shared
> >text? Perhaps the first instance of perl sets up some vast shared
> >memory segments and a way for the newcomers to link in to it and look
> >at the modules that have been loa
On Tue, 29 Aug 2000, Sam Tregar wrote:
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text?
> I don't believe you can simply "rearchitect it to make it shared text".
That depends on what the meaning of "it" is. :-)
If "
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>On Tue, Aug 29, 2000 at 01:46:17AM -, [EMAIL PROTECTED] wrote:
>>
>> This is a build failure report for perl from [EMAIL PROTECTED],
>> generated with the help of perlbug 1.32 running under perl v5.7.0.
>
>Now I tracked this one down (change #689
Sam Tregar wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text? Perhaps the first instance of perl sets up some vast shared
> > memory segments and a way for the newcomers to link in to it and look
> > at the modu
Well then. It is impossible to rearchitect it to make it shared
text? Perhaps the first instance of perl sets up some vast shared
memory segments and a way for the newcomers to link in to it and look
at the modules that have been loaded, somewhere on this system, and use
the common copy?
Henry Spencer once used some Larry-code (rn, actually) as a poster-child
for his "#ifdef Considered Harmful" talk.
--tom
Folks,
I think at this point we've beaten this one to death. The obvious
conclusions seem to be:
1) Removing all functions that do X (whatever X is) may or may not buy us
anything
2) Having a mechanism to automagically load in chunks of executable code
only when needed would be nice
3) It'd b
On Tue, Aug 29, 2000 at 12:50:46PM -0600, Tom Christiansen wrote:
> Henry Spencer once used some Larry-code (rn, actually) as a poster-child
> for his "#ifdef Considered Harmful" talk.
I can't argue with that, but actually the bulk of that monstrosity was
Richard-code, it was courtesy of gcc's me
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED]
m> whispered:
| Very well, then: I'll save it for an after-the-fact I-TOLD-YOU-SO,
| which, believe it or not, is truly *not* a pleasant thing to be
| able to say.
Tom, we appreciate your constructive comments and your hel
Chaim Frenkel wrote:
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
> SF> Or what about a variable attribute:
>
> SF> my $x : transactional
>
> SF> and making the effect completely lexical? Why would other scopes need to
> SF> see such variables?
>
> You haven't handled the multiple var
David L. Nicol writes:
> This handwringing naysaying is depressing.
Yes, it's depressing to find out there are problems in one's grand
plans. However, I'm very glad that people (including Tom) are
pointing out problems *before* we commit to a course of action.
Nat
On Tue, 29 Aug 2000, David L. Nicol wrote:
> Well then. It is impossible to rearchitect it to make it shared
> text? Perhaps the first instance of perl sets up some vast shared
> memory segments and a way for the newcomers to link in to it and look
> at the modules that have been loaded, somewh
Although Perl interpretation is divided into several passes (parser/lexer,
optimizer, tree/bytecode runner), all these passes are grouped together in
one binary. Under some memory-constrained conditions, it could be better if
each pass ran as its own program, passing the transformed data onto the
At 02:57 PM 8/29/00 -0400, John Porter wrote:
>But as for the semantics... how does perl handle this:
>
> for ($x,$y,$z) (@a1,@a2) { ... }
>and
> for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
>
>Making the case where the number of iterators == the number of arrays
>special may not be so
Chaim Frenkel wrote:
>
> We should be able to represent
> any packed structure. We should be able to handle anything that an
> pack/unpack format can currently handle.
> ...
> The raw structures could be passed between perl and the XS unchanged.
>
> the COBOL redefines capabilities.
> ...a met
On Mon, 28 Aug 2000 20:26:41 -0700, Nathan Wiger wrote:
> foreach (@str) { print "Got it" if match /\w+/, @str;
> if (/\w+/) { $gotit = 1 };
> }
> print "Got it" if $gotit;
>
>Now if DWIM just worked for email as well... ;-)
You mean, like grep?
print "Got it"
Nathan Wigner, disguised as Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
[...]
Gut feeling, I don't like this proposal. Examples coming up.
> Increases in namespace are basically always beneficial.
>
> =head2 Potential Problems
>
> This approach is not without its problems. These need to b
Peter Scott wrote:
>
> Yes, please. I view the flattening of lists as a feature, not a bug, and
> it has made Perl a lot easier to understand IMHO.
So... is an RFC forthcoming? Or shall I?
--
John Porter
We're building the house of the future together.
Andy Dougherty wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > I'd like to see every number bundled with a "precision" attribute.
>
> While that might be useful for simple calculations, I expect it would
> simply get in the way and slow things down for larger, more complex
> calcula
>>I'd like to see every number bundled with a "precision" attribute.
>That's not what I call a high-level language feature. People don't
>want to think about that, nor about machine-level precision issues.
>See REXX.
>In fact, I'd rather to see a painless and transparent int->float->bignum
>
At 03:24 PM 8/29/00 -0400, John Porter wrote:
>Peter Scott wrote:
> >
> > Yes, please. I view the flattening of lists as a feature, not a bug, and
> > it has made Perl a lot easier to understand IMHO.
>
>So... is an RFC forthcoming? Or shall I?
I mailed an RFC on multiple loop variables in for(
At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote:
>On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > I'd like to see every number bundled with a "precision" attribute.
>
>While that might be useful for simple calculations, I expect it would
>simply get in the way and slow things down for larger, mor
Tom Christiansen wrote:
> >Well, as I mentioned in another recent parallel thread, if C is to
> >be properly functionalized,
>
> Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
> expressible as functions.This isn't tcl!
Ah, the old "If you want Tcl, you know where to fin
Graham Barr wrote:
> Also it hash been
> suggested that it could potentially replace each
>
> for my($k,$v) (%hash) { ... }
Continuing my crusade for beefier prototypes, I can easily envision this:
for(\$\$\%&);
callable as
for ($k,$v) %h { }
--
John Porter
We're
It's probably worth reading through the Python Enhancement Proposals
(PEPs) to see if there's anything that makes sense to steal:
http://python.sourceforge.net/peps/
Nat
Dan Sugalski wrote:
>At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote:
>>On Tue, 29 Aug 2000, David L. Nicol wrote:
>>
>> > I'd like to see every number bundled with a "precision" attribute.
>>
>>While that might be useful for simple calculations, I expect it would
>>simply get in the way and slow
John Porter wrote:
>
> You know, I would like to pass code blocks in any arg position;
> I want sub foo(&\@&\@&) to be callable as
>
> foo { alpha() } @bravo { charlie() } @delta { echo() };
>
> No Cs, no commas.
And one further note: it would be nice if, given a prototype
which does
At 03:46 PM 8/29/00 -0400, Eric Roode wrote:
>Okay, brainstorming here ... bear with me.
>
>What if limit-of-error precision were tracked, as Perl tracks tainted
>variables when you tell it to?
Can't be done that way, unfortunately. You need to enforce significant
digits at every step of the cal
On Tue, 29 Aug 2000, David L. Nicol wrote:
> I'd like to see every number bundled with a "precision" attribute.
While that might be useful for simple calculations, I expect it would
simply get in the way and slow things down for larger, more complex
calculations.
Alas I don't think there's any
Al-
> In some of the OO stuff people (me included) wanted to see simple scalars be
> able to act "like" objects.
You'll be particularly interested in RFC's 159 and 161, and discussions
on -objects. Check out these emails in particular:
http://www.mail-archive.com/perl6-language-objects%40perl.
Jonathan Scott Duff wrote:
> I'm wondering how we get both
>
> for ($x,$y,$z) (@array) { ... }
>
> and
>
> for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it'
At 01:07 PM 8/29/00 -0600, Tom Christiansen wrote:
> >Now, every error is guaranteed to be an object. You can call some method
> >or check some attribute of it to find out if it was an exception. If
> >you're checking a system() or `` failure, you use it in numerical
> >context. If you're check
Christian Soeller wrote:
> Jeremy Howard wrote:
> > >
> > Ditto. As I said yesterday, my current preferred option is that a list
ref
> > of list refs will also support a multidimensional indexing syntax.
> > Furthermore, if it has a single basic data type and is declared
':compact'
> > it should b
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 within.
Buddha Buck wrote:
> I propose the use of ';' as a separator for index terms when accessing
> multi-di
Jeremy Howard wrote:
>
> I prefer the syntax I suggested yesterday:
>
> $a[[$i,$j,$k]];
>
> which also allows multiple elements:
>
> $a[[$i,$j,$k], [$x,$y,$z]];
The problem I have with the above is how similar it is to this:
@a[$i,$j,$k];
A little too close for comfort, personally. Bu
Hi,
> ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
> $foo[0,0];# uh-oh
>
>Then adding a new fundamental type and syntax is not only unnecessary,
>but silly.
Why do you think that individual elements are perl scalars? since we don't keep
strings in pidd
Baris wrote:
> Hi,
> > ^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
> > $foo[0,0];# uh-oh
> >
> >Then adding a new fundamental type and syntax is not only unnecessary,
> >but silly.
>
> Why do you think that individual elements are perl scalars? since w
This is a copy of the RFC I sent to the Librarian. I don't know when the
Librarian will publish it, but I don't want to wait any longer... We can
discuss it while he is compiling/classifying/publishing it.
--
=head1 TITLE
Proposed syntax for matrix element
Nathan Wiger wrote:
> And I'm assuming this only returns one element, right? Because if it
> returns a list it's not a $scalar. I think by this:
>
>$a[[$i,$j,$k], [$x,$y,$z]];
>
> You might actually mean this:
>
>@a[[$i,$j,$k], [$x,$y,$z]];
>
Yes, that's what I meant--sorry for the con
Christian Soeller wrote:
> Chaim Frenkel wrote:
>
> >
> > The current thinking in -internals is that list flattening will be
delayed
> > to as late as possible.
> >
> > One possiblity would be that only @_ would do any flattening. It would
> > walk each argument with an appropriate iterator to ret
>but surely wouldn't warrant a new data type.
There is no relation between my proposal in this email for special 2-d
syntax and having a new type for pdl's.
Baris.
*** REPLY SEPARATOR ***
On 8/30/00 at 8:06 AM Christian Soeller wrote:
>Baris Sumengen wrote:
>>
>> Hello,
>>
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
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
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
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
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 that a list ref
of list refs will also support a multidimensiona
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
Jeremy Howard wrote:
> >
> Ditto. As I said yesterday, my current preferred option is that a list ref
> of list refs will also support a multidimensional indexing syntax.
> Furthermore, if it has a single basic data type and is declared ':compact'
> it should be stored in a contiguous block of mem
I'd like to see a last-container-key attribute included as
a possibilty; and that attribute called ":n" to match the
argument of integer functions in introductory algebra. This
approach gives us
for $a @some_list {
print "$a is located at position ${a:n}\n";
};
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
> At 13:11 28/08/00 -0400, Steve Simmons wrote:
> >To tell the truth, this third item should probably should become
> >a separate RFC, and if you'd like to simply say one is forthcoming,
> >that'd be fine by me.
>
> What I really want
At 08:19 29/08/00 -0500, Jonathan Scott Duff wrote:
> > As far as I can see the current consensus is as follows:
> > 1. Implicit variable: nice but not really worth the trouble.
> > 2. Explicit variable between foreach and the array: might conflict
> > with other proposals.
> >
> 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
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.
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
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
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
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
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
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
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:
>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
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
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
>$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
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
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
1 - 100 of 315 matches
Mail list logo
