Chaim Frenkel wrote:
> The Bytecode representation should be mutable and contain enough iformation
> for type/data flow analysis.
What do you mean by "mutable"? Wouldn't the dataflow analysis for a
given bytecode be immutable? Or do you mean the implementation should
be hackable?
> (Do you think
Since no one else has taken this up, I'll start an initial draft.
=head1 TITLE
Rename the C operator
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: not yet assigned
=head1 ABSTRACT
The C opera
On Fri, Aug 04, 2000 at 12:36:35AM -0500, J. David Blackstone wrote:
> Perhaps stackable tie-ing and stackable filehandles can both be
> implemented as specific examples of something more general.
Perhaps, but I find it unlikely; stackable filehandles has to happen
at a much lower level. Althou
Nathan Wiger <[EMAIL PROTECTED]> writes:
> > You've taken the wrong approach. If you're writing a big program then
> > there should be *no* default scope. Any variable access is an error
> > unless that variable was my()ed or our()ed. That's basically what
> > 'strict' gives us.
>
> Fair enou
I eighth this (or whatever). Perhaps, though, in addition to adding a
zillion new command-line switches, Perl could check the name of the
executable?
funperl -pe 's/foo/bar/'
- vs. -
#!/usr/local/bin/bdperl # (-w, `use strict', etc. implied)
Rationale: The one thing a one-liner doesn
subscription information at http://dev.perl.org/
WORKING GROUP: perl6-language-strict
CHAIR: J. David Blackstone <[EMAIL PROTECTED]>
Daniel Chetlin <[EMAIL PROTECTED]>
MISSION:Discuss the use of the strict pragma in Perl 6
DEADLINE: 18 August 2000
DESCRIPT
On Fri, Aug 04, 2000 at 01:36:02AM -0400, Uri Guttman wrote:
>it looks like typechecking and named params should fork off into a subs
>subgroup. all of you with an itch to write an rfc, here is your chance.
Anyone want to put their hand up as a chair of such a sublist? Damian's
got the closest r
Ask, can we please have the following list:
Name: perl6-language-strict
Chairs: J. David Blackstone <[EMAIL PROTECTED]>
Daniel Chetlin <[EMAIL PROTECTED]>
Charter:Discuss the use of the strict pragma in Perl 6
Timescale: 2 weeks (finish August 18th)
Before anyone writes an RFC on names sub parameters, they should look
at the archives of perl5-porters where it has been discussed a fair amount.
A sample of what appeared to be rough-consensus syntax then:
sub myfoo(Dog $spot : alias, String $str : readonly, $bar);
Note the (more-or-le
> 1. put their hands up to write the "up for grabs" RFCs
I'll grab:
unlink() renamed
I believe the "Renaming line noise" one is already covered in RFC 17.
The localtime() one's still coming, I promise! It'll be good (I hope),
lots of great input.
> I'm *very* close to suggesting a "strict"
Before jumping in on this, keep in mind that Larry Wall has already
stated his intent to just plain _eliminate_ many of these special
variables. Most of them suffer from the "action-at-a-distance"
problem, meaning you change something somewhere and unexpected changes
occur elsewhere.
For exa
> "s" == skud <[EMAIL PROTECTED]> writes:
s> 1. put their hands up to write the "up for grabs" RFCs
i am working on one for flow control (event loops, threads, signals). i
should have a draft by this weekend. put it in the list of promised RFCs.
s> 3. let me know if you think an RFC ne
Bryan C.Warnock wrote:
> On Thu, 03 Aug 2000, Simon Cozens wrote:
> > On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > > Keep default Perl free of constraints such as warnings and strict.
> > >
> > > I second this.
> >
> > I third this. Perl is not, nor do I believe it ever shou
OK, here's my summary of language RFCs as they currently stand. As
I said before, this list will always be available from
http://infotrope.net/opensource/software/perl6/
I would appreciate if people could do the following:
1. put their hands up to write the "up for grabs" RFCs
2. work towards g
Peter Scott wrote:
>
> I'll say up front that I have no good idea as to how to implement this,
> hence the lack of RFC, but I think it's worth getting the ball rolling to
> see if there's enough collective intelligence and inclination to make
> something happen.
>
> OO inheritance is well define
Nathan Wiger wrote:
>
> > =head1 TITLE
> >
> > Keep default Perl free of constraints such as warnings and strict.
>
> I second this. If the current definition of "lexical" remains unchanged
> (which I strongly suspect it will),
Lexical scope has a standard non-Perl definition. It means you c
named parameters seem to be a popular item. i haven't seen much more
than a simple example syntax. how would the named params map onto or
modify @_? would the equivilent perl5 code just be
sub func {
my( $foo, @bar ) = @_ ;
blah ;
}
becomes:
Tom Christiansen wrote:
>
> > I have retained the title of "Lexical variables made default,"
> >because I still feel that that is the primary purpose of this change,
> >meaning that in future Perl documentation (books, manpages, classes (I
> >hope)) new Perl users will first be presented with va
At 11:04 PM 8/3/00 -0500, J. David Blackstone wrote:
> As the initial proponent of the opposing RFC, I feel I should make a
>response. Let the will of the Perl6 community and Larry Wall prevail.
> I'm sure we'll all be mostly happy, no matter where that takes us.
I will hitch my wagon to your
> Nathan Wiger wrote:
> > Because it has opportunity for bloat, I would suggest it should be in a
> > pragma:
> >
> >use strict 'prototypes';
>
> Bloat? What bloat? I don't want to *bloat* all my programs by sticking
> a zillion pragmas in just to turn on all the features that makes Perl 6
>
At 12:26 AM 8/4/00 -0400, Ted Ashton wrote:
>Thus it was written in the epistle of Perl6 RFC Librarian,
> >
> > =head2 Disadvantages
> >
> > Literally none have been broached on the various C mailing lists.
>
>Well, I'll take my shot at providing one: An at least %800 increase in the
>characters
Nathan Wiger wrote:
> Because it has opportunity for bloat, I would suggest it should be in a
> pragma:
>
>use strict 'prototypes';
Bloat? What bloat? I don't want to *bloat* all my programs by sticking
a zillion pragmas in just to turn on all the features that makes Perl 6
different from Pe
John Tobey wrote:
> The Perl 5 (and older) behavior may preclude some optimizations.
I can't think of any optimizations @_ assignment precludes.
If we don't analyze dataflow to figure out if a sub modifies its
args, then we just assume it will.
Is this just a style issue? Why would you allow it
On Thu, Aug 03, 2000 at 02:03:13PM -0400, Dan Sugalski wrote:
>
>I'd expect either the chair of the WG, or the person responsible for the
>broader area the WG lives in, will be ultimately responsible for saying No
>definitively.
I would expect that the WG head could somehow mark an RFC as unwan
On Thu, 03 Aug 2000, Simon Cozens wrote:
> On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > > Keep default Perl free of constraints such as warnings and strict.
> >
> > I second this.
>
> I third this. Perl is not, nor do I believe it ever should become, a B&D
> language by defa
Thus it was written in the epistle of Perl6 RFC Librarian,
>
> =head2 Disadvantages
>
> Literally none have been broached on the various C mailing lists.
Well, I'll take my shot at providing one: An at least %800 increase in the
characters used to make up these names. For quick hacks, this is
On Thu, Aug 03, 2000 at 07:27:18PM -0700, Nathan Wiger wrote:
>> if (want 'hash') { return %hash } # rather than eq
>
>I like this alot.
Works for me.
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins
On Thu, 03 Aug 2000, Chaim Frenkel wrote:
> What would be the method to _avoid_ emitting something?
>
> What would be the result of
>
> open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef
> $x++; # Prints 3
>
> What makes something a 'real' void so that it would
On Thu, 03 Aug 2000, Chaim Frenkel wrote:
> Its my maintainence hat on.
>
> Picture some poor shmo, the regular guy is off on his two week vacation,
> in some out the way place without his cell phone. And a production problem,
> or the million dollar client, needs this yesterday.
>
> And he does
As the initial proponent of the opposing RFC, I feel I should make a
response. Let the will of the Perl6 community and Larry Wall prevail.
I'm sure we'll all be mostly happy, no matter where that takes us.
Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> Perl5 is usable with no hassle as a quick-a
On Fri, 4 Aug 2000, Damian Conway wrote:
>> > Fair enough. If we were going to do it I would like to see it extend to:
>> >
>> > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
>> >
>> > }
>>
>> Is there an RFC for this yet? If not, I think there needs to be. I
Nathan Wiger wrote:
>
> > I have retained the title of "Lexical variables made default,"
> > because I still feel that that is the primary purpose of this change
>
> First off, I think this is a great idea in principle. However, I don't
> think it goes nearly far enough in the implementation.
On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote:
> > Keep default Perl free of constraints such as warnings and strict.
>
> I second this.
I third this. Perl is not, nor do I believe it ever should become, a B&D
language by default. "Making easy things easy", remember that?
--
> Besides, named arguments will solve this (in fewer chars even :-)...
>
>$user = 'nwiger';
>sub whois ($user) {
># ...
>}
>
> Damian
Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)
So will these be "automatically-my()ed"? Or wil
=head1 TITLE
Organization and Rationalization of Perl State Variables
=head1 VERSION
Maintainer: Steve Simmons <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 17
=head1 ABSTRACT
Perl currently contains a large number of state and status variab
> =head1 TITLE
>
> Keep default Perl free of constraints such as warnings and strict.
I second this. If the current definition of "lexical" remains unchanged
(which I strongly suspect it will), I think Perl should remain loosely
typed by default. Make people add
use strict;
use warnings;
> However, I do think there's something to be said for a "quick-and-dirty"
> script out of the box that can distinguish between sub{} vars and other
> vars ala C:
>
>$user = 'nwiger';
>sub whois {
>($user) = @_;# different var
># ...
>}
> You've taken the wrong approach. If you're writing a big program then
> there should be *no* default scope. Any variable access is an error
> unless that variable was my()ed or our()ed. That's basically what
> 'strict' gives us.
Fair enough. I've heard several good analyses against my idea,
> > Fair enough. If we were going to do it I would like to see it extend to:
> >
> > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
> >
> > }
>
> Is there an RFC for this yet? If not, I think there needs to be. I think
> this would be really cool.
I'll have a pro
> Fair enough. If we were going to do it I would like to see it extend to:
>
> sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) {
>
> }
Is there an RFC for this yet? If not, I think there needs to be. I think
this would be really cool.
Because it has opportunity for bloat, I would suggest i
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 1 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 6
=head1 ABSTRACT
Prior to version 5, all implementations of Perl were designed with
only dynamic (global)
Thus it was written in the epistle of Nathan Wiger,
> I don't know of an easy solution. I don't think we should touch chomp or
> chop. Maybe someone should write a module that offers alternate versions
> for those that want them?
How often does the return value from chomp or chop get used? The c
> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.
Great analysis. I think this sounds like an excellent idea.
> Some related issues:
>
> 1) Did Larry or did he not mention somethin
In writing up the RFC on removing/fixing $[line noise here] variables,
I've decided to leave out the following suggestion:
On Tue, Aug 01, 2000 at 06:47:41PM -0700, Nathan Wiger wrote:
> Alan Burlison wrote:
> >
> > Steve Simmons wrote:
> >
> > > I'd prefer that we break these vars out into a s
Nathan Wiger writes:
> I argue we should fundamentally shift this thinking in Perl 6. Let's
> truly have "lexical variables made default".
Ugh. Baby, bathwater.
If I'm writing a big program, then I want to have to declare all
variables so that Perl can catch errors for me. That's the big
benef
> The suggestion was the open() return a filehandle object, so may
> I suggest
>
>$fh = open("| cat -v | sort | lpr") or die ;
>$pid = $fh->pid;
I like. I'll add it.
Version 2's gonna be *huge*...
-Nate
> I'd've written that more like
>
> $data_axed = chop($var);
> $charcount = chomp($var);
>
> Or something. People really do find those two functions confusing.
> Is this something we'd like to address by having versions that don't
> take LVALUES?
I don't know. It is true that this is s
=head1 TITLE
Keep default Perl free of constraints such as warnings and strict.
=head1 VERSION
Maintainer: Daniel Chetlin <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 16
=head1 ABSTRACT
Perl5 is usable with no hassle as a quick-and-dirty pr
Nathan Wiger said:
> > What lexical scope should $x be _implicitly_ declared in? Maybe, just
> > maybe, we need a my $x at the top to tell us it is outside the scope of
the
> > first reference. Otherwise we get three different lexical variables,
and an
> > undefined value warning at run time.
>
> if (want 'hash') { return %hash } # rather than eq
I like this alot.
-Nate
> In fact, you may as well go the whole way and say that all IO is done via
> optimised IO objects (ie include sockets etc). IO::File and friends
> without the overhead. All of the current open functions simply pass these
> objects around.
I'll stick this in there, definitely. This is just what I
> Are you saying they don't look Perlish now?
>
> And no, all you guys, I'm not trying to shoot down a monadic,
> object-returning open. Please don't assume that.
As funny as it sounds, yes. Mind you, they're not really too weird. But
compared to how most other functions have turned out working
> What lexical scope should $x be _implicitly_ declared in? Maybe, just
> maybe, we need a my $x at the top to tell us it is outside the scope of the
> first reference. Otherwise we get three different lexical variables, and an
> undefined value warning at run time.
You're right, great point. T
What would be the method to _avoid_ emitting something?
What would be the result of
open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef
$x++; # Prints 3
What makes something a 'real' void so that it would print. Vs. not
having something that would catch the
The problem with lexical variables being made default, in earnest, is
simple, and error-prone:
code;
if ( condition )
{ more code;
$x = 'did then'';
} else
{ more code;
$x = 'did else';
}
print $x;
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x
On Thu, 3 Aug 2000, Nathan Wiger wrote:
> > sysopen() should probably be included in the list as well.
>
> Good point.
>
In fact, you may as well go the whole way and say that all IO is done via
optimised IO objects (ie include sockets etc). IO::File and friends
without the overhead. All of th
> sysopen() should probably be included in the list as well.
Good point.
-Nate
> I have retained the title of "Lexical variables made default,"
> because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something rad
>While a function style or quoted form
>comment might seem clever, and even Perlish due to its syntax, it doesn't help
>the author of the code/comments readily distinguish them. What good are
>comments if you can't find them when you need them?
Sounds like an argument for :10,20s/^/###/ style co
Larry Wall wrote:
> A less obvious strategy is to try to see where various marginal
> features could be subsumed under some more powerful feature.
In general, this is a good^Wgreat concept to avoid multitudinous small features.
> To some extent,
I'm glad you qualified this...
> you see this w
On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote:
> Peter Scott <[EMAIL PROTECTED]> writes:
> > If we get a good-looking exception throwing/catching mechanism and
> > syntax, this may not matter.
>try {
> java
>}
>catch (Exception e) {
> think again
>}
I
Its my maintainence hat on.
Picture some poor shmo, the regular guy is off on his two week vacation,
in some out the way place without his cell phone. And a production problem,
or the million dollar client, needs this yesterday.
And he doesn't notice the use printvoidvalues.
So the previous occ
This should be automated, with the Chair (or her henchman) triggering
the creation, initial members, and announcment.
(What about a timebomb, that needs to be reset regularly, sort of to
encourage coming to a completion)
> "s" == skud <[EMAIL PROTECTED]> writes:
s> Yes indeed:
s> List na
Versions, dear boy. Versions. Don't forget versions.
We will need them.
(This really belongs on -internals. Reply-to: adjusted)
And while were here, does anyone understand kpathsea? Would it be a
win. I think it would.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> lexer saw a n
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> That's the beauty of the entire existing Perl code base -- every
KF> program presents its complete source code to the interpreter. Once
KF> bytecode and native function calls arrive it will be a lot harder
KF> to get dataflow analysis implemen
I have an RFC coming on this.
(I know, I know, I keep promising, but none appear.
I'll unload the first 10 or so later today, the gods willing)
Damian
Peter Scott <[EMAIL PROTECTED]> wrote:
> So user subroutines should not be able to reproduce the semantics, of,
> e.g., sysread()? I was hoping for more equality in this respect (user subs
> being able to do anything builtins can) rather than less.
Let me clarify. Only unprototyped subs are a
> I have retained the title of "Lexical variables made default,"
>because I still feel that that is the primary purpose of this change,
>meaning that in future Perl documentation (books, manpages, classes (I
>hope)) new Perl users will first be presented with variables declared
>as lexicals with
On Fri, 4 Aug 2000, Simon Cozens wrote:
> On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> > Reading through the docs for perl prototypes I see that there is a
> > reference to "named parameters" being a possibility in future versions of
> > perl.
> >
> > Does anyone have a more co
At 08:18 PM 8/3/00 -0400, John Tobey wrote:
>Unprototyped subs should not be allowed to modify their callers' data
>simply by assigning to elements of the arg array. This form of
>passing by reference is obsolete now that Perl has hard references and
>C<\$> in prototypes. The feature is confusin
>if you want to have something like switch/case it is a good idea to use
>the 'case' of pascal, because it is easy to use and it is really clear.
>the 'switch/case' of c is (in my opinion) is not good for a language
>like perl which claims to be practical.
Please, please, *PLEASE* read through Da
This is not quite finished yet, as I read the rest of the C-- garbage
collection paper.
-John
=head1 TITLE
Elements of @_ should be read-only
=head1 VERSION
Maintainer: John Tobey <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
=head1 ABSTRA
>Tom Christiansen wrote:
>> #if 0
>> ...
>> #endif
>Ahem, has somebody already mentioned -P (perldoc perlrun)?
>If you want 'em, you already got 'em!
I'm in the choir, preacher! IWTFM. :-)/3
--tom
>If we were to agree to make the basic syntax of open() something like:
> $object = open [$filename], [$class];
>There's a lot of cool stuff we could do. In the simplest "mostly looks
>like Perl5" cases, open() can work like shown above. In fact, I'd be
>plenty happy with just this, since it m
John Tobey wrote:
>
> "J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> > Thanks for the feedback, everyone. I now believe that what we
> > really want is what so many have suggested, i.e., making strict 'vars'
> > the default (in essence, at least).
>
> Sorry if this was mentioned already.
I'll say up front that I have no good idea as to how to implement this,
hence the lack of RFC, but I think it's worth getting the ball rolling to
see if there's enough collective intelligence and inclination to make
something happen.
OO inheritance is well defined and the ways of implementing
On Fri, Aug 04, 2000 at 05:27:59AM +1000, Damian Conway wrote:
>> > Perl's similarity to English is one of the things that makes it Fun.
>>
>> OTOH, being fun (which I admit it is) is one of the reasons many
>> people don't want to think Perl is a serious language.
>>
>>
"J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> Thanks for the feedback, everyone. I now believe that what we
> really want is what so many have suggested, i.e., making strict 'vars'
> the default (in essence, at least).
Sorry if this was mentioned already. If this change is adopted, I
wou
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Stefan Moch) wrote:
> if you want to have something like switch/case it is a good idea to use
> the 'case' of pascal, because it is easy to use and it is really clear.
> the 'switch/case' of c is (in my opinion) is not good for a languag
Larry Wall wrote:
> Some of these concepts are not going to be global concepts in Perl 6.
> The per-filehandle variables will be attached to filehandle objects.
THANK YOU!! (Breathes a sigh of relief.)
I still remember the fateful day when I discovered $", which made my
CGI script outpu
On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote:
> Reading through the docs for perl prototypes I see that there is a
> reference to "named parameters" being a possibility in future versions of
> perl.
>
> Does anyone have a more concrete example of what was intended there?
sub mari
> Several people have requested strong typing as a feature, but have been shot
> down with reasons such as "it's un-Perl-like", with an added "it'll slow
> everything down for those who don't want it".
Definitely.
> Unfortunately, accessing and manipulating tied variables is incredibly slow,
> s
Thanks for the feedback, everyone. I now believe that what we
really want is what so many have suggested, i.e., making strict 'vars'
the default (in essence, at least).
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of thi
--snip--
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
>[EMAIL PROTECTED] wrote:
>> Perl's similarity to English is one of the things that makes it Fun.
>OTOH, being fun (which I admit it is) is one of the reasons many
>people don't want to think Perl is a serious language.
So what?
--sinp
Michael Fowler <[EMAIL PROTECTED]>:
>
> use typing; # place your fingers on the home row..
>
> my integer $quux = 4;
I believe that would have to be
integer my $quux = 4;
at least in perl5...
--
John Porter
=head1 TITLE
Stronger typing through tie.
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 02 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 15
=head1 ABSTRACT
Strong typing of variables can be implemented through the already-existent
Martyn J. Pearce wrote:
> <...> what I would like to discuss adding to the language is
>
> 1) a means to signal an early exit to the iterator,
> 2) a means to tell we're at the end of a list without having to
> evaluate the list length as we start
> 3) a much more lightweight, and language built-i
On Fri, Aug 04, 2000 at 05:24:43AM +1000, Damian Conway wrote:
> Tad pointed out:
>> I will RFCify this within the next few days (unless someone
>> can shoot it down right now).
>
> http://www.csse.monash.edu.au/~damian/Perl/want.proposal
I withdraw my threat of RFCification, and bow
On Thu, Aug 03, 2000 at 05:57:45PM +0100, Hildo Biersma wrote:
>'AMQ9506' => [ "Channel '($channel_patt)' has ended because",
> "Channel" ],
>
>'AMQ9508' => [ "The connection attempt to queue manager '(.*?)'
> failed with reason code ($reason_patt)\\.",
>
Buddha Buck wrote:
> I suggest that the last be
> "Status: postponed" instead of "Status: tabled".
"deferred"
--
John Porter
Larry Wall wrote:
>
> As long as everyone realizes that I might reject a good many "Good"
> things ...
Oh, natch!
> For embedded comments, we might rather see some kind of
> macro facility that could turn qc// or any other quoted form into a
> list of zero or more tokens.
This is precisely wh
> Reading through the docs for perl prototypes I see that there is a
> reference to "named parameters" being a possibility in future versions of
> perl.
>
> Does anyone have a more concrete example of what was intended there? (I'm
> assuming that since it was mentioned that ther
At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote:
>BTW, I propose that RFCs have a Status: field as part of the VERSION.
>Here are some possible values that I can see:
>
>Status: accepted # we all agree that it should go in
>Status: rejected # we all agree that it shouldn't go in
>Stat
Reading through the docs for perl prototypes I see that there is a
reference to "named parameters" being a possibility in future versions of
perl.
Does anyone have a more concrete example of what was intended there? (I'm
assuming that since it was mentioned that there was a debate on the issue
s
> I don't care particularly if you ignore dissenters. They can have
> their own counter-RFC. All we're doing is making suggestions to
> Larry, not regulating nuclear weapons or planning a space mission.
I used to feel like that too, until folks from the space agencies of
two countries
At 09:06 PM 8/3/00 +0200, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 07:21 PM 8/3/00 +0200, Johan Vromans wrote:
> > >Larry Wall <[EMAIL PROTECTED]> writes:
> > > > Theoretically, we'd like to make subs run as fast as ops.
> > >I'd say that the distinction between subs
At 09:03 PM 8/3/00 +0200, Johan Vromans wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > More importantly, the more primitives that perl provides, the wilder
> > and more useful things people will be able to do.
>
>Not quite. Its the functions that are provided that matter, not
>whether they
hi,
if you want to have something like switch/case it is a good idea to use
the 'case' of pascal, because it is easy to use and it is really clear.
the 'switch/case' of c is (in my opinion) is not good for a language
like perl which claims to be practical.
cu stefan
--
Diese eMail wurde unter
Larry Wall wrote:
> Note in particular that multi-line comments
> are something we *could* have added at any time, but chose not to.
> This means you're gonna have to argue a little harder for it than you
> would for something that wasn't possible before, but that we think
> might become possible
> > Perl's similarity to English is one of the things that makes it Fun.
>
> OTOH, being fun (which I admit it is) is one of the reasons many
> people don't want to think Perl is a serious language.
>
> Not saying we should eliminate all the fun; but keeping something
> on t
1 - 100 of 220 matches
Mail list logo
