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
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
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 enough. I've
Since no one else has taken this up, I'll start an initial draft.
=head1 TITLE
Rename the Clocal 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
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
Please do not send your RFCs to both perl6-rfc and perl6-$working_group.
The RFC librarian will automatically forward your RFC with a number on
it, which is kinda neater.
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open Source development, consulting and solutions
Level
John Porter [EMAIL PROTECTED] writes:
But a standardized macro facility would be nice. Although --
wouldn't it have to parse perl? Or else have a wholly distinct
grammar?
Several macro processors exist and are easily available. I do not see
the need to duplicate (parts of) their
Tom Christiansen [EMAIL PROTECTED] writes:
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?
Damian Conway wrote:
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Before it's too late - please, don't impose either '$self' or '$this',
but make this a per-module choice. I deal with people of both these
religions...
Hildo
Please, please, *PLEASE* read through Damian's fine paper on this
entire matter before rendering judgment.
URL?
http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt
Damian
Johan Vromans wrote:
You missed the point.
If you need 6+ lines of code for each elementary error check, this is
what is going to happen (and it _does_ happen in almost every Java
program I've seen):
try {
open file
while read a record
process its contents
Before it's too late - please, don't impose either '$self' or '$this',
but make this a per-module choice. I deal with people of both these
religions...
What about '$me'? It ties in nicely with 'my' (although perhaps for the
wrong reasons), it's half as much typing as 'self' or 'this' and
What about '$me'? It ties in nicely with 'my' (although perhaps for the
wrong reasons), it's half as much typing as 'self' or 'this' and we get
to annoy both sets of religious zealots at once. :-)=
You took the words right out of my...err...fingers!
Although, of course, it will
In article [EMAIL PROTECTED], Damian Conway
[EMAIL PROTECTED] writes:
Please, please, *PLEASE* read through Damian's fine paper on this
entire matter before rendering judgment.
URL?
http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt
Very interesting. I look forward to
On Fri, Aug 04, 2000 at 08:16:17AM +1000, Jeremy Howard wrote:
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
"skud" == skud [EMAIL PROTECTED] writes:
skud My $DEITY, someone sedate this man before he drowns us all in
skud Perl RFCs! K.
From the subject line, I thought it was another mailing list for me to
send in a subscription request!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc.
Tom Christiansen [EMAIL PROTECTED] writes:
[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?
Well said.
Damian Conway [EMAIL PROTECTED] writes:
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
Tom Christiansen [EMAIL PROTECTED] writes:
True, but maybe a lower precedance keword is needed like we did
or || and . I think someone suggested "then"
print $string1, $string2, "\n" then return 3 if $cond;
then again, maybe not.
Why not just piss everybody off?
return 3
Some related issues:
1) Did Larry or did he not mention something about dealing with
indirect object more cleanly?
Maybe clarify this just a little. I don't think I was present for this
discussion.
That's just the indirect object slot ambuiguity annoyance. See the
OO chapter in
How often does the return value from chomp or chop get used? The confusion
would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to have any such found be converted to some kind
of
Several macro processors exist and are easily available. I do not see
the need to duplicate (parts of) their functionality in perl.
Personally, I'd even trow out -P.
Well, possibly, but especially if a cpp-like source filter module
is included standard.
--tom
Tom Christiansen [EMAIL PROTECTED] writes:
But that, precisely, was my point: Arrays *and* hashes. If there is more than
one plural whatzitz, then why can't there be more than one singular whatzitz?
(and don't say, "because plural *means* more than one" :-). If having a
filehandle
Johan Vromans [EMAIL PROTECTED] writes:
=head1 ABSTRACT
Perl distinguishes named operators and functions. For Perl6, this
disctinction can be dropped.
Will this then work?
sub foo {
my $func = shift;
$func(@_);
}
foo(\print, "foo");
foo("print", "foo");
Nathan Torkington [EMAIL PROTECTED] writes:
Tom Christiansen writes:
What is the purpose of ghettoizing everying cohering topic? Making
us subscribe to infinite lists to wear us down?
Yes.
If you really care about the topic, you'll join the list. If you
don't care, stay off the
On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote:
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.
I don't agree. The problem is somewhere else, namely the problem that
Ilya Z. brought up: the fact that there is no
On Fri, 04 Aug 2000, Peter Scott wrote:
The punctuation versions do at least have the merit of i18n :-) I don't
see any "use French" scripts out there yet...
I had a tentative 'use Arabic;' module, but couldn't figure out how
they'd say "setuid". (Plus, my Arabic skills have drastically
The descriptions in perlfunc etc. are not 100% complete.
Then send a patch.
There are some features that are still not documented. Therefore, it is
not possible to mathematically prove that a largish program is correct.
Your "therefore" is misplaced or misguided. Formal proof systems
of
Hello!
I am thinking about the perl compiler, and I thought if somebody
avoid using the "eval $scalar", the compiled code (perl to C
compiled code) may not contain a full perl interpreter. If it is the
case, we must say to any module developer: Don't use "eval $scalar"!
This
Thus it was written in the epistle of Tom Christiansen,
If we were selecting dubious features to shoot (and I think we are),
then the fact that $^F and $ are the same is one I'd kill--by zapping
the latter, too.
I'm afraid I couldn't argue very convincingly against it, though I'd be truly
On 03 Aug 2000 22:23:08 -0400, 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
Exactly. I can think of even more cases:
* What do
On Thu, Aug 03, 2000 at 10:33:21PM -0700, Peter Scott wrote:
A constant topic
of discussion is how to make Perl more accessible and friendly to the the
newcomer,
And we will get a chance to discuss that very thing right here,
(I already think we 're going to need a sub-list for that
Thus it was written in the epistle of Tom Christiansen,
How often does the return value from chomp or chop get used? The confusion
would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to
Ask, can we please have this one too?
List name: perl6-language-subs
Chairs: Tim Jenness [EMAIL PROTECTED]
Damian Conway [EMAIL PROTECTED] (if he wants it)
Charter:Draft, discuss, and revise RFCs relating to subroutines
in Perl 6, eg named
Thus it was written in the epistle of Tom Christiansen,
Has having $ and its riends caused trouble
for you?
Only embarrassment at explaining it.
While I only use one ^Form (and I suspect that that is true of most
programmers), I still remember the thrill at discovering that the one ^Form
=head1 TITLE
Immediate subroutines
=head1 VERSION
Maintainer: Jean-Louis Leroy
Date: 04 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 18
=head1 ABSTRACT
This very simple construct, inspired by the Forth language, makes the
parser extensible by Perl code, providing
=head1 TITLE
Overloadable and ||
=head1 VERSION
Maintainer: Jean-Louis Leroy
Date: 04 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 20
=head1 ABSTRACT
It should be possible to overload and ||, for this has very
legitimate uses.
=head1 DISCUSSION
The reason often
I was having a think about the volume of discussion on -language and
whether it's workable. From my point of view, I'd prefer that it was
about half as busy, maybe even less. Fifty posts a day I could easily
cope with and spend time thinking about; a hundred and fifty, or two
hundred and fifty,
I propose a sublist "perl6-language-errors" to cover the following
topics:
- exceptions
- $! and $?
- any other error handling topics, as seen from a language viewpoint
If you wish to say yes/no to this proposal, please email me privately.
If you have detailed comment, please post on-list.
Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
I don't like giving up low-level control either, but imagine something
like this:
$port = shift ||
I propose a sublist, perl6-language-flowcontrol, to discuss the
following:
- case/switch
- uri's looping stuff
- anything else related to flow control, from a language perspective
Let me know what you think or if you're interested in chairing this group
(uri? sounds like your kind of thing?)
IME, I find it more dangerous to do behind-the-scenes hand holding than
to simply teach them the hows and whys of the "right way."
Exactly.
The key word above is "encourage". You're not really encouraging
anything - you're now having the language mandate particular constructs,
without
This one should be discussed on -subs as well, please.
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Tom Christiansen wrote:
Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I meant "the
Tom Christiansen wrote:
Thats just because IO::Socket is done wrong
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
Sorry, wrong verbage. I meant "the
At 08:20 AM 8/4/00 -0400, John Tobey wrote:
Ken Fox [EMAIL PROTECTED] wrote:
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
At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
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.
If we
At 09:10 AM 8/4/00 -0600, Tom Christiansen wrote:
At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
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
Tom Christiansen writes:
Maybe we should address this? If we're keeping syscalls just because a
possible replacement module is just written wrong, we should fix this.
Why would we ever remove a syscall!?!?
I vote for migration to a module. If you're going to use the
long-winded form of
Why would we ever remove a syscall!?!?
I vote for migration to a module.
And sysopen and fcntl and waitpid and ioctl
Tom Hughes wrote:
Is there any difference, besides the default fall through of
the C switch statement?
I believe Pascal's case statement allows only one statement to be executed
for each case. This is, IMHO, a pain in the ass. Personally, I prefer to see
something more like C's switch, but I
=head1 EXAMPLES
# multiline comments
sub comment
{
return '';
}
use immediate 'comment';
sub foo
{
# ...
comment {
this is a multiline comment;
the call to comment is executed at parse time
and returns an empty string that replaces
the whole call in the parse stream };
}
I
On Fri, Aug 04, 2000 at 01:37:09AM -0500, J. David Blackstone wrote:
=head1 IMPLEMENTATION
Csave
If I had my druthers, save() would be it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Instead of "local", how about...
reuse
redef
our_temp
Perl6 RFC Librarian wrote:
=head1 TITLE
Rename the Clocal operator
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
NetZero Free
Bart Lateur wrote:
On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote:
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.
I don't agree. The problem is somewhere else, namely the problem that
Ilya Z. brought up: the
On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote:
You missed the point.
If you need 6+ lines of code for each elementary error check, this is
what is going to happen . . .
You're correct, but that's not what I was suggesting. The magic words are
`for each elementary error
On Fri, Aug 04, 2000 at 02:59:06PM -, Perl6 RFC Librarian wrote:
Howeverm it Iis possible to cause a Ccase statement to "fall-through". If a
Cnext is executed within a Ccase block, control is immediately
transferred to the statement following the Ccase block.
For example:
At 02:45 PM 8/4/00 +, Perl6 RFC Librarian wrote:
=head1 TITLE
Immediate subroutines
This does complicate the job of the parser/lexer rather considerably. While
not a reason to not do it, if we're going to do this we should do it with
significant force and flexibility that we don't need to
On Fri, Aug 04, 2000 at 09:05:38AM -0700, Nathan Wiger wrote:
Suggestion: Can we manually renumber this "RFC 0"? This should be the
first one at the top of the list, not buried somewhere within. my($.02).
We *shouldn't* need to spell this out for people.
It really, really terrifies me that we
On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote:
At 02:31 PM 8/4/00 +0200, dLux wrote:
My suggestion is: declare "eval $scalar" as a bad guy.
It's not just string eval. It's also do FILE and require.
Which you need at runtime, even in compiled code, to run external
At 05:16 PM 8/4/00 +0100, Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Indirect calls might not be a problem, depending on how much flow analysis
we can do in the optimizer. While that won't be much in the
on-the-fly-compile version (a 10s runtime with a 50s compile time's not
[ Cc'd back to -language, hope you don't mind ]
On Fri, Aug 04, 2000 at 09:08:18PM +0200, Jean-Louis Leroy wrote:
[EMAIL PROTECTED] writes:
Please take discussion on this RFC to the forthcoming -subs sublist.
Really. Just hold off for a little while until the list is up. Should
be really
Hear, hear!
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Gisle Aas wrote:
foo(\print, "foo");
I think it's critical that built-ins be reference-takeable,
just like user-defineds.
But they [dw]on't work right.
sub CORE::push { push(@_);
$fn = \CORE::push;
$fn-(@some_array, now, some, list);
--tom
Simon Cozens [EMAIL PROTECTED]:
=item Functional Programming
Just because Perl has a Cmap operator, this doesn't make it a
functional programming language. Perl has always been squarely
procedural,
It has also been roundly object-oriented and rectangularly functional,
at least since
I don't much care for m4; it's not so much better than cpp to be
worth the notice.
*Strongly* disagree.
--tom
Tom Christiansen wrote:
I think it's critical that built-ins be reference-takeable,
just like user-defineds.
But they [dw]on't work right.
Um -- why not? Why can't we make then work right in perl6?
As my example demonstrated, it's because there's no run-time
application of content
As my example demonstrated, it's because there's no run-time
application of content coercion templates. And I don't think
s/ent/ext/
At 01:30 AM 8/5/00 +0900, Simon Cozens wrote:
On Fri, Aug 04, 2000 at 12:24:01PM -0400, Dan Sugalski wrote:
At 02:31 PM 8/4/00 +0200, dLux wrote:
My suggestion is: declare "eval $scalar" as a bad guy.
It's not just string eval. It's also do FILE and require.
Which you need at runtime,
At 02:42 AM 8/5/00 +1000, [EMAIL PROTECTED] wrote:
[ Cc'd back to -language, hope you don't mind ]
On Fri, Aug 04, 2000 at 09:08:18PM +0200, Jean-Louis Leroy wrote:
[EMAIL PROTECTED] writes:
Please take discussion on this RFC to the forthcoming -subs sublist.
Really. Just hold off for a
Tom Christiansen wrote:
I don't much care for m4; it's not so much better than cpp to be
worth the notice.
*Strongly* disagree.
O.k., what I really meant was, When they're both incapable of doing
the sorts of things I want a macro language to do, does it matter
that one is gobs more
Jonathan Scott Duff wrote:
Perl. :-)
Isn't this what source filters is all about?
There's something to be said for there being a standard, always-on
preprocessor, the way C has cpp. While -P makes available a nice
usable preprocessor for perl, not much code uses it, because not
many
On Fri, 4 Aug 2000, Bart Lateur wrote:
I think it's a bad idea. I would rather do it as the C64 did: use a very
short function name as an alternative to "print".
P "This gets printed!", "\n", "Yeah!\n";
Just like perldl already allows(but that's an intereactive shell so we
try
If it's a language thing (as your mailing list field in your RFC
indicates) then it should be on -subs.
If it's a precompiler thing then, um, doesn't that fall under internals?
Nope. Internals implements (and possibly says "You want us to do
*what*!?!?"), language designs. Get us a design and
On Fri, Aug 04, 2000 at 01:07:07PM -0400, Uri Guttman wrote:
i like perl6-language-flow better.
Yeah, so do I. I did wonder whether maybe it wasn't clear enough,
though.
s - case/switch
try/catch
Any thoguhts on the errors sublist? should this be there, or in -flow,
or what?
/me takes 1
At 16:24 03/08/2000 -0700, Peter Scott wrote:
Is it at all possible to define interfaces for tie-ing that would
facilitate stacking? Do we care?
I think we should care, notably for tied handles. It would be very useful
to be able to pipe ties easily.
-- robin b.
Always remember you're
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Why not allow for the choice of the name of self, perhaps through a pragma?
use self = 'self';
use self = 'this';
or something along those lines -- since it's currently up to the devleoper
anyway. Somethign
At 01:23 PM 8/4/00 -0400, John Porter wrote:
Jonathan Scott Duff wrote:
Perl. :-)
Isn't this what source filters is all about?
There's something to be said for there being a standard, always-on
preprocessor, the way C has cpp. While -P makes available a nice
usable preprocessor for
I say this as a Unix weenie, albeit a Unix *user* rather than a Unix
*programmer*. I'm quite used to navigating the Unix filesystem but,
having never braved Unix systems programming, had no conceptual link
between deleting/"rm"ing files, and the term "unlink". It tooks me
quite a bit of
One of my many RFCs will include a proposal for a $SELF variable along
those lines.
Why not allow for the choice of the name of self, perhaps through a pragma?
use self = 'self';
use self = 'this';
or something along those lines -- since it's currently up
i think damian's influence on perl6
is our real triple top secret weapon.
This realization has hit me on the head really hard.
My prediction is that Perl6 will have to be dual-credited.
I doubt it: Lucifer doesn't get a by-line on the Bible.
There's only one Larry.
From [EMAIL PROTECTED] Sat Aug
5 04:36:31 2000
Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8])
by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id EAA20410
for [EMAIL PROTECTED]; Sat, 5 Aug 2000 04:36:31 +1000 (EST)
Received: from
OK I will raise to the bait
I think it's a bit unfair to say that PDL people have failed to 'bite',
there was quite a bit of discussion on our list after your post. Also
some concern about how much of perl6 is vapourware.
I am game to take part in discussions.
It has always been apparent to
I'm not quite buying into this.
There are some things that are just easier with this style of thinking.
Its a higher level construct. Akin to telling your interior decorator
that you'd like the furniture to match the wallpaper. You've left
out all the details but the decorator can easily see
Thus it was written in the epistle of Damian Conway,
I have an RFC coming on that :-)
I think Skud asked the wrong questiong :-). Would you please submit a
comprehensive of the topics on which you are not about to produce an RFC. That
will allow others to focus their work. Thank you very
Could a way be found to control the flow so that the next case (not always
the one next in the order of the statment) could be executed? For example
you have cases 1-10. You want all odd cases to also execute case 9 and the
even cases to also execute case 10. So in case 3 you
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL =item Functional Programming
PRL Just because Perl has a Cmap operator, this doesn't make it a
PRL functional programming language. Perl has always been squarely
PRL procedural, and so things like Creduce and Ccurry and other
Also on the issue of loop unrolling and efficient looping.
PDL has what we call 'threading'.
This allows a C-level function to specify the dimensionality of
the arguments it accepts. For example a function addtoline() which
hyptheticaly adds a constant to a row vector might
have a 'signature'
On Sat, Aug 05, 2000 at 05:09:28AM +1000, Damian Conway wrote:
Not necessary.
switch ($val) {
case 3 { print "three"; goto odds }
case 4 { print "three"; goto evens }
And "goto" could be spelt "next" too? That would make sense to me,
but
Ariel Scolnicov:
It so happens that remove() is standard C (library) for removing a
file. It therefore makes sense to use *that* name, if any change is
made.
IMHO, it's poorly named (though using remove() at least has the virtue of
not conflicting with/overloading the existing "delete").
Not a bad solution, at least for the example I put forth. I like the ability
to have the specific as well as the general in the case statement ('2' and
'__%2 != 0'). Thanks.
Could a way be found to control the flow so that the next case (not
always
the one next in the order of the
5. Other operating systems/ file systems have, or could have
hypothetically, the same operation. I.e. just because NTFS
doesn't have multiple links now (or does it?) doesn't mean
it won't in the future.
NTFS does support hard links right out of the box, although the first
On Fri, 4 Aug 2000, Tuomas Lukka wrote:
On 4 Aug 2000, Ariel Scolnicov wrote:
Well, first of all,
10:100, 30:200
is not the same: in Perl it comes out as
10..100, 30..200
10, 11, ... , 100, 30, 31, .., 200
Additionally, generically it would not necessarily
Sorry for the broadcast, but anyone else having problems with perl6-rfc?
I sent two separate RFC's in from separate mail servers but haven't seen
anything happen with them. It's been a good hour, too.
Thanks,
Nate
Does "goto odds" mean start evaluating all cases after the
"odds:" label? Meaning that the below is equivalent to the above?
I think this is what the original poster was asking; if not, I'd
like to ask it!
That's exactly what it means.
switch ($val) {
Great idea! (Don't accuse me of apathetic lurking!)
I suspect it already has a different meaning, based on operator precedence rules,
left to right evaluation, etc., but I strongly doubt there is much use of it in
that manner, and would encourage this redefinition to be used instead.
Perl6 RFC
On Fri, 4 Aug 2000 16:33:41 -0700, Damien Neil wrote (in part):
Damien On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman
Damien wrote:
The C (POSIX.1) remove() function is NOT just unlink() in
drag.
Damien Not everywhere, at least:
Damien REMOVE(3) FreeBSD Library Functions Manual
Gosh, just unlink() leave it as it is.
--tom
On Fri, 4 Aug 2000, Damien Neil wrote:
My opinion on the unlink()/remove() debate: Ignoring our history is
foolish. Why suddenly transform every Perl program that uses unlink(),
which has been valid for over a decade, into one using an outmoded and
deprecated construct? unlink() is, in my
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
:
: =head2 Disadvantages
:
: Literally none have been broached on the various Cperl6 mailing lists.
Potential disadvantage, depending on implementation:
The loss of distinctiveness. Right now, when one sees a $linenoise
variable, they notice its
1 - 100 of 147 matches
Mail list logo
