Re: RFC 179 (v1) More functions from set theory to manipulate arrays

Which kind of "difference"?

RFC 179 (v1) More functions from set theory to manipulate arrays

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE More functions from set theory to manipulate arrays =head1 VERSION Maintainer: Gael Pegliasco <[EMAIL PROTECTED]> Date: 30 August 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 179 =head

Re: {....} if condidion

>> You don't want do have a postfix { ... } if condition. It's evil >I don't see how this is any worse than a postfix while() Look closer: do { ... } while does not require the reader to scan down to find out the condition *BEFORE* the loop is entered. With an if, it does. >> Because it hide

Re: {....} if condidion

> You don't want do have a postfix { ... } if condition. It's evil I don't see how this is any worse than a postfix while() do { asd; asdf; asdf; asf; asdf; asdf; sad; fasdfa; sdf; asdf; asdf; asf

Re: RFC 175 (v1) Add C keyword to force list context (likeC)

Damian Conway wrote: > > And has anyone pointed out that C is just: > > sub list {@_} Hey, an easy IMPLEMENTATION section! I like it. ;-) No, I hadn't gotten that far. But you're right (surprise :). The above sub is an list constructor just like "() =" is. Awesome. I guess that throws

Re: Proposal: use Perl5

Jerrad Pierce wrote: > > Since everyone seems intent on breaking backward compatibility I don't think this is at all true, but I also don't think the overall idea of a Perl5 module is necessarily a bad one. However, my hope would be that we do Perl 6 smoothly enough and get the docs written wel

Re: RFC 175 (v1) Add C keyword to force list context (like C)

[EMAIL PROTECTED] wrote: > > (yes, I'm in an RFC-commenting mood today...) > > On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote: > >Add C keyword to force list context (like C) > > Makes sense to me. Does it connect in any way with Damian's generic > want() function? Implic

Re: RFC 175 (v1) Add C keyword to force list context (like C)

> On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote: > >Add C keyword to force list context (like C) > > Makes sense to me. Does it connect in any way with Damian's generic > want() function? Only in that it would explicitly cause C to return true. And has anyo

Re: Proposal: chop() dropped

Tom Christiansen wrote: > > >I'll second that motion. We already have lots of ways of removing the > >last character of a string if that's what we really need. > > But they're slow and hard to read. I think the word "drop" should be clarified as "dropped from the core binary". In a very cool

Re: Proposal: use Perl5

On Wed, Aug 30, 2000 at 04:43:56PM -0400, Jerrad Pierce wrote: >Since everyone seems intent on breaking backward compatibility >(Okay, so no one is explicitly setting out to do so, it is merely often >dismissed as a non-issue). How about an RFC be done proposing that >perl6 ship with a module name

Re: RFC 175 (v1) Add C keyword to force list context (like C)

(yes, I'm in an RFC-commenting mood today...) On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote: >Add C keyword to force list context (like C) Makes sense to me. Does it connect in any way with Damian's generic want() function? K. -- Kirrily Robert -- <[EMAIL PROTECTED]> --

Re: RFC 173 (v1) Allow multiple loop variables in foreach statements

On Wed, Aug 30, 2000 at 02:21:19AM -, Perl6 RFC Librarian wrote: > >Allow for a list of loop variables in for(each) statements, i.e. & e.g., > > foreach my ($x, $y, $z) (@list) { ... } Hear, hear. I like this one :) K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/

Re: RFC 2 (v3) Request For New Pragma: Implicit

On Wed, Aug 30, 2000 at 04:53:46PM -0400, Bryan C . Warnock wrote: >On Wed, 30 Aug 2000, Michael Maraist wrote: > >> Good idea, but you have it backwards.. If anything, there should be an >> "explicit" keyword.. >> Remember, we want >> >> % perl -p -e 's/foo/bar/g' file.txt > >Oh, I know. I thr

Re: RFC 2 (v3) Request For New Pragma: Implicit

On Wed, Aug 30, 2000 at 10:31:48AM -0400, Michael Maraist wrote: >> Request For New Pragma: Implicit > >Good idea, but you have it backwards.. If anything, there should be an >"explicit" keyword.. This resonates well with me. I had a funny feeling about "use Implicit" and I wasn't sure what it w

Re: Proposal: chop() dropped

On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote: >chomp() is best used for chop()s main raison d'etre, removing $/ >from a string. I say we drop chop(). Works for me. Are you going to RFC it? K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source

Re: Proposal: chop() dropped

>I would actualy like to see chop expanded to allow a variable number of >characters to be removed and a sister function to cut the head off. Yes I >know you can do this with substr but sometimes when you want the performance >and need to cut up a string into fields. Lets say the new function is c

Re: Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

> Actually this is pretty cool, add a = and turn it into a variable > declaration: > >my format $FORMAT = <<'.'; > @, @ > $stuff, $junk > . > > And that looks pretty similar to Perl 5. ;-) Yah, but it's frought with the possibility of confusion. I can easily s

RE: Proposal: chop() dropped

>>I'll second that motion. We already have lots of ways of removing the >>last character of a string if that's what we really need. >But they're slow and hard to read. I would actualy like to see chop expanded to allow a variable number of characters to be removed and a sister function to cut

Re: Idea: minor %hash changes

>As far as I can tell reset %x currently tries to reset any >variables which start with either % or x even though no variable >can start with %... ~/perl ${"%percent"} = "Quoth the raven"; print ${"%percent"}, "\n"; reset("%"); print ${"%percent"}, "\n"; Quoth the raven Sure looks like it starts

Re: Proposal: chop() dropped

On Wed, 30 Aug 2000 16:14:35 -0600, Tom Christiansen wrote: >>I say we drop chop(). > >So code that says > >chop($k,$v) > >will need to say > >for ($k,$v) { s/.\z//s } > >or else something like: > >for ($k, $v) { substr($_, length() - 1) = '' } > >I'm not sure I find either of those

Re: Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

Tom Christiansen wrote: > format $fh < @, @ > $stuff, $junk > EO_FORMAT Actually this is pretty cool, add a = and turn it into a variable declaration: my format $FORMAT = <<'.'; @, @ $stuff, $junk . And that loo

Re: Idea: minor %hash changes

Tom Hughes writes: > I must admit it had never occurred to me that somebody might > deliberately use keys or values to achieve that, but I guess > somebody might be relying on it without realising it. while (($k,$v) = each %foo) { last if ...; } keys %foo;# reset the iterator w

Re: Idea: minor %hash changes

In message <[EMAIL PROTECTED]> Nathan Torkington <[EMAIL PROTECTED]> wrote: > Resetting an each() should be done in some other way than calling > keys() or values(). Perhaps reset(%hash)? I'm subfond of the current > reset() semantics (symbol table crackheadery + single-match regexp >

the C JIT

Dan Sugalski wrote: > I do want to have a set of C/XS/whatever sources as part of the test suite > as well--right now perl's test suite only tests the language, and I think > we should also test the HLL interface we present, as it's just as > important in some ways. I want to see Perl become a f

Re: Proposal: chop() dropped

>I presume that line disciplines will be object-oriented and inherit from >some base class; therefore a bare chomp will use the line terminator from >that base class and for the others, you could do something like >$fh->chomp($line) to do chomping specific to a particular filehandle. Make >se

Re: Idea: minor %hash changes

>Tom Christiansen writes: >> But %hash->BUCKET_USE() should return what's currently there. >Do you really use this information? Really? I have no objection >to supplying a way to discover it, but this might even be in an >external module rather than built into the language given how rarely >it'

Re: Proposal: chop() dropped

At 04:36 PM 8/30/00 -0600, Tom Christiansen wrote: > >the reason that they're duplicatable with other features, while I want > >to drop chop because its main purpose has now been replaced with the > >far superior chomp. > >Except that chomp() relies upon the ueberglobal $/ variable, >irrespective

Re: Idea: minor %hash changes

Tom Christiansen writes: > But %hash->BUCKET_USE() should return what's currently there. Do you really use this information? Really? I have no objection to supplying a way to discover it, but this might even be in an external module rather than built into the language given how rarely it's used

Re: Proposal: chop() dropped

Tom Christiansen writes: > So code that says > > chop($k,$v) > > will need to say > > for ($k,$v) { s/.\z//s } > > or else something like: > > for ($k, $v) { substr($_, length() - 1) = '' } I don't think chop() is an operation that's done often enough for either of the things ab

Re: Proposal: chop() dropped

>the reason that they're duplicatable with other features, while I want >to drop chop because its main purpose has now been replaced with the >far superior chomp. Except that chomp() relies upon the ueberglobal $/ variable, irrespective of the source of the data being chomped. --tom

Re: Proposal: chop() dropped

Ed Mills writes: > Duck & cover Nate- I sugested that weeks ago and the flames are just dying > down in my mailbox.. Whoops, sorry. I didn't realize that had already been submitted. I just read through the mail archive and didn't see much in the way of flames there. J.S. Duff wants to keep th

Re: Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

> > No-one AFAICT has yet brought up formats, and what would happen > > to them if bareword filehandles go the way of the dodo. I'm about to propose that formats be replaced with a mechanism of Text::Autoformat::form (with some extensions). Damian

Re: Idea: minor %hash changes

>I was against the idea of hash context, but I'd love it if: > foreach ($k,$v) (%hash) { >... > } I'd like for Perl to emit a warning if people try for (%hash) or its aliases. That is, if a foreach loops sole content is a %{...} at compile time, grinch. --tom

Re: Idea: minor %hash changes

>%hash in scalar context should return what scalar(keys(%hash)) >currently does. But %hash->BUCKET_USE() should return what's currently there. And a simple boolean (read: don't care) use shouldn't waste time looking for keys, really, but should be internally optimized to do the current reasonabl

Re: Proposal: chop() dropped

>I'll second that motion. We already have lots of ways of removing the >last character of a string if that's what we really need. But they're slow and hard to read. --tom

Re: Proposal: chop() dropped

>chomp() is best used for chop()s main raison d'etre, removing $/ >from a string. I say we drop chop(). So code that says chop($k,$v) will need to say for ($k,$v) { s/.\z//s } or else something like: for ($k, $v) { substr($_, length() - 1) = '' } I'm not sure I find either of

Idea: minor %hash changes

(I'm going to RFC these if nobody presents any killer complaints about them, it's just that writing RFCs is more work than I want to go through for tiny little changes like these, especially if they turn out to be dumb). %hash in scalar context should return what scalar(keys(%hash)) currently doe

Re: Proposal: chop() dropped

Duck & cover Nate- I sugested that weeks ago and the flames are just dying down in my mailbox.. It'll be an interesting experiement in "community behavior" however. If your proposal is widely acclaimed or even seriously considered, while mine was summarily dismissed, then it may be safe to ass

Re: Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

>Peter Scott wrote: >> >> No-one AFAICT has yet brought up formats, and what would happen to them if >> bareword filehandles go the way of the dodo. >Here's some thoughts I've been tooling with. If we take advantage of the >indirect object syntax, we can actually make format into a member >funct

Re: {....} if condidion

You don't want do have a postfix { ... } if condition. It's evil to have do { asd; asdf; asdf; asf; asdf; asdf; sad; fasdfa; sdf; asdf; asdf; asf; asdf; asd; as;

Re: RFC 33 (v2) Eliminate bareword filehandles.

>David L. Nicol wrote: >> >> >> 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? >How about barewords are always interpreted as function names (by defaul

Re: RFC 2 (v3) Request For New Pragma: Implicit

>On the other hand, I hardly ever use $_ in main-stream programming. I >always perform: >for my $var ( .. ) { .. } Certainly I seldom *mention* $_, but I sure use it a lot, as in for (@array) { s/foo/bar/ } It's not something I'd like made Law, but I do advise my beginning students that

Re: RFC 52 (v2) List context return from filesystem functions

At 03:35 PM 8/30/00 -0600, Tom Christiansen wrote: > >=head2 Hash Context > > >When the result is assigned to a hash, the list returned could be the names > >of the unsuccessfully modified files and their corresponding C<$!> errors. > >Um, but we don't have hash context. :-( We will :-) RFC 21:

Re: RFC 52 (v2) List context return from filesystem functions

>=head2 Hash Context >When the result is assigned to a hash, the list returned could be the names >of the unsuccessfully modified files and their corresponding C<$!> errors. Um, but we don't have hash context. :-( --tom

Re: RFC 168 (v1) Built-in functions should be functions

>Doesn't that tend to lead us in the direction of pack madness where we >end up with yet another 'sub language' within perl. We've already got >pack specifiers and regexen and the 'old' prototyping stuff. I'm not >arguing *against* these things you understand, I'm just vaguely >worried. As you h

Re: RFC 2 (v3) Request For New Pragma: Implicit

On Wed, 30 Aug 2000, Michael Maraist wrote: > Good idea, but you have it backwards.. If anything, there should be an > "explicit" keyword.. > Remember, we want > > % perl -p -e 's/foo/bar/g' file.txt Oh, I know. I threw it in because someone mentioned wanting to turn it off. (There may have

Re: switch s/statement/operator/

> could a case operator be overloadable? C isn't an operator, it's (half of) a control statement. In a sense, the existing proposal already allows C to be "overloaded". If your switch value is a subroutine, then the C value is passed to that subroutine, which can then do...anything. > I kn

Proposal: use Perl5

Since everyone seems intent on breaking backward compatibility (Okay, so no one is explicitly setting out to do so, it is merely often dismissed as a non-issue). How about an RFC be done proposing that perl6 ship with a module named Perl5. Which one can use to remedy most breakings between the two

Re: Proposal: chop() dropped

On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote: > chomp() is best used for chop()s main raison d'etre, removing $/ > from a string. I say we drop chop(). I'll second that motion. We already have lots of ways of removing the last character of a string if that's what we really

Proposal: chop() dropped

chomp() is best used for chop()s main raison d'etre, removing $/ from a string. I say we drop chop(). Nat

Re: RFC 157 (v1) Delete C and C commands.

On Tue, Aug 29, 2000 at 04:24:36PM -0400, Stephen P. Potter wrote: > Deprecated, superseded, obsolete, whatever... it all comes down to the same > thing. There is a better way to do it. Says you. I say otherwise. Offer both ways, this ain't Python. > | tie %hash, 'AnyDBM_File', 'some

Re: Do we really need eq?

At 01:31 PM 8/30/00 -0500, David L. Nicol wrote: >Dynamic types-checking slows us down of course, but with both, the >dynmaic type will only be required when it isn;t clear, and that clarity >will keep perl6 instructors with full classrooms. I can guarantee you that keeping instructor's classroom

Re: Do we really need eq?

Fisher Mark wrote: > * Units of measure are optional; > * Units of measure are fast; and > * Implementing units of measure don't appreciably slow down computations > that don't use units of measure. enforced types without automatic conversions does all this, the matches are made once at compile-

Re: RFC 132 (v3) Subroutines should be able to return an lvalue

Johan Vromans wrote: > > Hi David, > > [Quoting David L. Nicol, on August 29 2000, 19:27, in "Re: RFC 132 (v3) Sub"] > > > With the enhanced C operator, subroutines can dynamically decide > > > what to return. > > > > With context-based polymorphism, the decision can be made staticly. > > Could

Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

Peter Scott wrote: > > No-one AFAICT has yet brought up formats, and what would happen to them if > bareword filehandles go the way of the dodo. Here's some thoughts I've been tooling with. If we take advantage of the indirect object syntax, we can actually make format into a member function:

RE: RFC 176 (v1) subroutine / generic entity documentation

> #File: Foo.pm > sub foo : doc( In:scalar - int - foo identifier >Out:array - decomposed foo >Effects: Queries Foo DB >Exceptions: DBI, "bad foo id" > EOS > { This is an interesting and powerful idea, but I can't help thinking that it needs to be

Re: RFC 52 (v2) List context return from filesystem functions

At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: > >>My worry is that it seems like this would return > >>an empty list on success, so: > >> > >> @foo = chmod 755, "bar", "baz", "quux" > >> or die "Whoops, died on success!"; > >> > >> > >>This seems to me to go contrary t

RE: Do we really need eq?

Al Lipscomb writes: >I was wondering about maybe being able to store these > attributes as > optional parts of the scalar. Something like this (please > don't get hung up > on the details, I am not much of a designer): > >my($amt,$hours,$total); >$amt->{TYPE} = "DOLLARS"; >$total->{

RE: RFC 168 (v1) Built-in functions should be functions

John Porter writes: > Ah, the old "If you want Tcl, you know where to find it" non-argument. > > "Closures?""No! This is Perl, not Lisp!" > "Objects?" "No! This is Perl, not Smalltalk!" > "Patterns?""No! This is Perl, not Snobol!" > "Subroutines?" "No! This is Perl, not Basic!" >

Re: RFC 173 (v1) Allow multiple loop variables in foreach statements

At 11:05 AM 8/30/00 -0400, John Porter wrote: > > The potential parsing difficulty I came up with was how to tell that > > > > foreach ($a,$b,$c) (@list) ... > > > > was not > > > > foreach $_ ($a, $b, $c) (@list) ... > > > > Graham tells me that the required parentheses and block braces

Re: Globs, (brrr) scalar filehandles, prototypes.

At 10:19 AM 8/30/00 -0400, Jerrad Pierce wrote: >Not a huge issue, but I hadn't seen anyone else bring it up. >If in fact: > bareword filehandles are ditched > globs are killed > prototypes are potentially touched. > >perlsub >sub myopen (*;$) myopen HAN

Re: {....} if condidion

> >$x =10, $z =15 if $y > 12; # 8 click shorter > > Should work now. I just tested it in 5.6, but I think that's been valid > since Perl4 or earlier. ]- yep my mistake...sorry :") > >instead of this : > > > >if ($y > 12) {$x =10; $z =15} ; > > > >4 keyboard click shorter - Shift+( and Shift+)

Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

Jarkko Hietaniemi wrote: > > By saying $hashref->{[LIST]} instead of $hashref->{{LIST}}, > > the only thing you would change is the semantics of the expression, > > Huh? Unless I missed something I didn't propose using $hashref->{[]} > anywhere... I used $ref->{{LIST}} and $ref->[[LIST]]. Rig

Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

On Wed, Aug 30, 2000 at 11:10:54AM -0400, John Porter wrote: > > Snatch two syntax constructs away from the jaws of illegal syntax and > > an unfortunate syntax, and make them useful weapons of the Perl > > arsenal. The constructs are: > > > > $ref->[[LIST]] > > $ref->{{LIST}} > > >

Re: {....} if condidion

At 05:52 PM 8/30/00 +0100, raptor wrote: >hi, > >We now can say : > >$x = 10 if $y > 12; > >It will be good if this also work.( i.e. block before if ). > >{$x =10; $z =15} if $y > 12; do {$x = 10; $z = 15} if $y > 12; works. >or > >$x =10, $z =15 if $y > 12; # 8 click shorter Should work now.

Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

> Snatch two syntax constructs away from the jaws of illegal syntax and > an unfortunate syntax, and make them useful weapons of the Perl > arsenal. The constructs are: > > $ref->[[LIST]] > $ref->{{LIST}} > > The proposed respective meanings: > > $ref->[$elem[0]]->[$ele

Re: RFC 168 (v1) Built-in functions should be functions

John Porter <[EMAIL PROTECTED]> writes: > Damian Conway wrote: > Well, as I mentioned in another recent parallel thread, if C is to > be properly functionalized, I deliberately stated "built-in functions", not "keywords". Please consult Tom's list and my addendum: Tom Christiansen <[EMAIL PRO

Re: RFC 168 (v1) Built-in functions should be functions

Peter Scott <[EMAIL PROTECTED]> writes: > I think you can't just leave it at that; the implication of this > requirement is that there should be a prototype for print's optional > filehandle. I count on Larry's promise to do something about the indirect object stuff. -- Johan

Re: RFC 173 (v1) Allow multiple loop variables in foreach statements

: Peter Scott <[EMAIL PROTECTED]>: > > =head2 Alternatives > > While C is frequently adduced as an alternative, this requires an > array instead of just a list, and is destructive to boot. > > =head1 IMPLEMENTATION > > The potential parsing difficulty I came up with was how to tell that > >

{....} if condidion

hi, We now can say : $x = 10 if $y > 12; It will be good if this also work.( i.e. block before if ). {$x =10; $z =15} if $y > 12; or $x =10, $z =15 if $y > 12; # 8 click shorter instead of this : if ($y > 12) {$x =10; $z =15} ; 4 keyboard click shorter - Shift+( and Shift+) = iVA

Re: RFC 168 (v1) Built-in functions should be functions

Tom Christiansen <[EMAIL PROTECTED]> writes: > >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, a

Re: RFC 33 (v2) Eliminate bareword filehandles.

David L. Nicol wrote: > > > 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? How about barewords are always interpreted as function names (by default); and

Re: RFC 2 (v3) Request For New Pragma: Implicit

- Original Message - From: "Perl6 RFC Librarian" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, August 29, 2000 8:59 PM Subject: RFC 2 (v3) Request For New Pragma: Implicit > Request For New Pragma: Implicit Good idea, but you have it backwards.. If

Re: RFC 168 (v1) Built-in functions should be functions

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. Well, "indirect object synt

Re: RFC 168 (v1) Built-in functions should be functions

Tom Christiansen wrote: > > I don't know what's happening with indirect objects, but the nastiness > whereby you can only use unsubscripted scalars is quite the crock. > You know, where you can say > > print $fh "stuff\n"; > and > <$fh> > > But are not (well, in the second you can, but

Globs, (brrr) scalar filehandles, prototypes.

Not a huge issue, but I hadn't seen anyone else bring it up. If in fact: bareword filehandles are ditched globs are killed prototypes are potentially touched. perlsub sub myopen (*;$) myopen HANDLE, $name sub mypipe (**) mypipe READHA

Re: RFC 122 (v1) types and structures

Ariel Scolnicov wrote: > > Functional languages that do this are usually lazy Yes, that's what I meant. > That means that when you create > the structure the `foo' field stores a closure which evaluates to the > desired value. If the field is never accessed, the closure is never > evaluated

Re: RFC 33 (v2) Eliminate bareword filehandles.

On Wed, Aug 30, 2000 at 02:47:46AM +0200, Bart Lateur wrote: > On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote: > >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 expre

RE: RFC 176 (v1) subroutine / generic entity documentation

Wohoo! REBOL-isous > sub foo : doc( < Function: Foo > In:scalar - int - foo identifier > Out:array - decomposed foo > Effects: Queries Foo DB > Exceptions: DBI, "bad foo id" > EOS > { And the liste alternatives really seem rather ugly though How about sub foo ($$,DOC) { } Sin

Re: switch s/statement/operator/

Now, just to mess with your head a bit ;) could a case operator be overloadable? I know the conditional operator currently cannot be overloaded, but it seems it should be possible. difficulty is another thing though. Greg London

Re: RFC 167 (v2) Simplify C Syntax

>Doesn't dropping the requirement for a terminating ';' make life >harder for the parser? It doesn't seem like that's a criterion people have been applying to any of this. Unfortunately. --tom

Re: RFC 52 (v2) List context return from filesystem functions

>>My worry is that it seems like this would return >>an empty list on success, so: >> >> @foo = chmod 755, "bar", "baz", "quux" >> or die "Whoops, died on success!"; >> >> >>This seems to me to go contrary to the way perl tends to work... are >>there any other functions (be

Re: RFC 33 (v2) Eliminate bareword filehandles.

Tom Christiansen <[EMAIL PROTECTED]> writes: > >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 an

Re: RFC 167 (v2) Simplify C Syntax

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > =head1 DESCRIPTION > > One of the most common mistakes I make is forgetting a C<;> after > C, probably because I'm thinking ``if'' and an if doesn't > require a C<:> after it's closing C<}>. I'll type, for example, > > $cond and do { >