RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism

2000-08-24 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Omnibus Structured Exception/Error Handling Mechanism =head1 VERSION Maintainer: Tony Olekshy [EMAIL PROTECTED] Date: 08 Aug 2000 Last Modified: 23 Aug 2000 Version: 2 Mailing List:

Re: RFC 63 (v4) Exception handling syntax

2000-08-24 Thread Peter Scott
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote: PRL Exceptions are objects belonging to some CException class. Cthrowing PRL an exception creates the object; therefore, CEXCEPTION above is just a PRL class name (possibly including some C::). PRL PRL The Cexception function is just syntactic

Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism

2000-08-24 Thread Jonathan Scott Duff
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote: =head1 TITLE Omnibus Structured Exception/Error Handling Mechanism Woohoo! catch Alarm = { ... } catch Alarm, Error = { ... } catch $@ =~ /divide by 0/ = { ... } The = here seems like useless syntax to me.

Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism

2000-08-24 Thread Jonathan Scott Duff
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote: But I initially wanted to do without the = ... unfortunately that would require another keyword to handle the EXPR case and it didn't seem worth it. Not necessarily. catch { EXPR } { ... } # probably not

Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

2000-08-24 Thread Chaim Frenkel
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: JH "The first operation done on the return value of open() shall be defined() JH or you shall regret your pitiful existence."? (a flag on the scalar coming JH from open that makes any other op than defined() to die and defined() clears JH the

Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

2000-08-24 Thread Jarkko Hietaniemi
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote: "JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: JH "The first operation done on the return value of open() shall be defined() JH or you shall regret your pitiful existence."? (a flag on the scalar coming JH from open that

Re: Exception handling [Was: Re: Things to remove]

2000-08-24 Thread Glenn Linderman
Tony Olekshy wrote: Glenn Linderman wrote: I do recall seeing this quote; however, replacing AUTOLOAD is a very specific instance of resuming from or retrying a fault condition. And even though a retry mechanism could be generalized from AUTOLOAD to handling other conditions, it was

Re: RFC 119v2: Object neutral error handling via exceptions

2000-08-24 Thread Glenn Linderman
Tony Olekshy wrote: Yes, well, at this point I must re-iterate that (in light of reasons for the existence of a try keyword that I have explained in other messages), what you've written is the same as: try { ... } finally { do_something(); } Yes, they are equivalent. And note that

Re: Why $@ should be structured data.

2000-08-24 Thread Glenn Linderman
Tony Olekshy wrote: There you have it. That's why RFC 88 uses structured data for $@. That's a good argument, one that I have no quarrel with. As an enhancement to eval/die, this would make it more flexible for checking conditions. And with appropriate stringification, it is upward

Re: Why except and always should be a seperate RFC.

2000-08-24 Thread Glenn Linderman
Tony Olekshy wrote: Other than for the except and always clauses, RFC 199 is very similar to RFC 88. I like the idea behind except and always, but I think the proposed implementation could be dramatically simplified. The first thing to realize is that just because 119 doesn't say "try"

Re: Why fatal errors aren't special.

2000-08-24 Thread Peter Scott
At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote: By building up a non-fatal error handling technique on top the existing fatal error handling technique, you are forcing code that assumes it will die to behave differently, when you wrap a try block around it. Now it will only "maybe" die.

Re: Structured exception handling should be a core module.

2000-08-24 Thread Tony Olekshy
Peter Scott wrote: At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote: In fact, not only would I be pleased and honoured to author the Perl 6 core Try.pm module, I'm already working on a Perl 5 standard reference implementation. Peter, I think we should make this approach more clear in RFC

Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

2000-08-24 Thread Chaim Frenkel
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: But the drawback would be that the actual victim may not be the primal cause. sub foo { my $fh = open(); ... Lots more code ... return $fh; } $victim = foo; print $victim "I'm helpless"; JH Tough. Not a nice attitude. The

Re: On the case for exception-based error handling.

2000-08-24 Thread Tony Olekshy
Glenn Linderman wrote: Tony Olekshy wrote: Glenn Linderman wrote: actually wrapping a bunch of code inside a try block affects how that code reacts to die, thus affecting the behavior of the program that previously used die to mean terminate the program. Hang on, this

RE: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like with or express

2000-08-24 Thread Brust, Corwin
-Original Message- From: Bart Lateur [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 23, 2000 7:00 PM To: [EMAIL PROTECTED] Subject: Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like "with" or "express" On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-24 Thread Dave Rolsky
On Thu, 24 Aug 2000, Hildo Biersma wrote: Don't impose your religion on others. If people want 'this' instead of 'self', that should be just fine. It should be pretty easy to define the appropriate $ME-reader like this: use ObjectStyle 'self'; or use ObjectStyle 'Java'; for

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-24 Thread Michael Maraist
sub do_stuff { my $self = self; $self-{STATE}-{something} = @_; } sub error { carp @_ if self-config('VerboseErrors'); } I've never really seen anything like this before in other languages (Is that good or bad?). The closest is Java's odd use of the

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

2000-08-24 Thread Bart Lateur
On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote: It's a pain if you want to support both function-oriented and object-oriented calling forms, as CGI.pm does. For example, you can use both of these: print header; print $r-header; with CGI.pm. Now you need a self_of_default special

Re: RFC 144 (v1) Behavior of empty regex should be simple

2000-08-24 Thread Tom Christiansen
I propose that this 'last successful match' behavior be discarded entirely, and that an empty pattern always match the empty string. I don't see a consideration for simply s/successful// above, which has also been talked about. Thas would also match expected usage based upon existing editors.

Re: RFC 150 (v1) Extend regex syntax to provide for return of a hash of matched subpatterns

2000-08-24 Thread Tom Christiansen
This is useful in that it would stop being number dependent. For example, you can't now safely say /$var (foo) \1/ and guarantee for arbitrary contents of $var that your you have the right number backref anymore. If I recall correctly, the Python folks addressed this. One might check

Re: RFC 150 (v1) Extend regex syntax to provide for return of ahash of matched subpatterns

2000-08-24 Thread Kevin Walker
At 11:23 AM -0600 on 8/24/00, Tom Christiansen wrote: This is useful in that it would stop being number dependent. For example, you can't now safely say /$var (foo) \1/ and guarantee for arbitrary contents of $var that your you have the right number backref anymore. Good point. Thanks.

Re: RFC 153 (v1) New pragma 'autoloader' to load modules on-demand

2000-08-24 Thread Tom Christiansen
A main goal for Perl 6 is to make it faster, more compact, and lighter weight. This means moving lots of former core functions into modules. Andy D once posted something showing empirical evidence that this hypothesis is in fact *FALSE*. And I was taught that given a false hypothesis, nothing

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

2000-08-24 Thread Nathan Wiger
Chaim Frenkel wrote: Why this limitation? If the lvalue is a fundemental type (whatever that is) everything works as if the lvalue were actually in place sub foo { return $a } foo =~ s///;# same as $a =~ s///; This is not the type of lvalue sub that this RFC

Re: Exception handling [Was: Re: Things to remove]

2000-08-24 Thread Glenn Linderman
Tony Olekshy wrote: Glenn Linderman wrote: Just to point out that fatal is, indeed, as several people keep saying, truly in the eye of the catcher. That said, none of the currently proposed mechanisms permit "resume from fault" semantics, much less "resume from hardware fault"

[OT] How to pronounce 'www' (was Re: ... as a term)

2000-08-24 Thread Daniel Chetlin
On Wed, Aug 23, 2000 at 11:43:04PM -0400, Uri Guttman wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) [snip of other possibilities] the variation i learned somewhere was "wuh wuh

Re: [OT] How to pronounce 'www' (was Re: ... as a term)

2000-08-24 Thread Bart Lateur
On Wed, 23 Aug 2000 20:58:02 -0700, Daniel Chetlin wrote: I use "dub dub dub", which I picked up at Intel. I find it much easier to pronounce quickly than anything that uses an approximant. http://x74.deja.com/[ST_rn=ps]/getdoc.xp?AN=603967285 I do like "wibbly". Or "wibble". It has a

Re: RFC 133 (v1) Alternate Syntax for variable names

2000-08-24 Thread David Corbin
Michael Maraist wrote: my var; # declaring a scalar my array[]; # declaring an array my hash{}; # declaring a hash Though the declarations seem fine, I assume that you propose this to be optional at usage time, since variable interpolations such as "xxx${var1}xxx${var2}xxx"

RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl

RFC 147 (v1) Split Scalars and Objects/References into Two Types

2000-08-24 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Split Scalars and Objects/References into Two Types =head1 VERSION Maintainer: Nathan Wiger [EMAIL PROTECTED] Date: 23 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 147

OT: pronouncing www (was: Re: ... as a term)

2000-08-24 Thread Dave Storrs
On Thu, 24 Aug 2000, Bart Lateur wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) "The world"? This problem only exists in English! We pronounce it something similar to "way

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Jarkko Hietaniemi
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Dan Sugalski
At 10:56 AM 8/24/00 -0600, Tom Christiansen wrote: Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing,

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Markus Peter
--On 24.08.2000 10:56 Uhr -0600 Tom Christiansen wrote: The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Depends on taste I guess... Also, they

Re: OT: pronouncing www (was: Re: ... as a term)

2000-08-24 Thread Tom Christiansen
The "www" in e.g., "www.netscape.com" is pronounced, IMO, in the same way as other useless, should-be-obvious punctuation. It's silent. Seems like something you should take up with RFC 819, or maybe with RFC 881, considering that they and their ramifying successors all seem to be in flagrant

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Tom Christiansen
While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and

Re: OT: pronouncing www

2000-08-24 Thread Eric Roode
At our company, we pronounce "www" as "dub-dub-dub". The first syllable of the letter "w", three times. Very easy to say quickly. "dub-dub-dub-dot-perl-dot-com". Try it. -- Eric J. Roode, [EMAIL PROTECTED] print

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Nathan Torkington
We need a way to mix eq, the things to be compared, and the operation to be done on them before they are compared: lc{ $foo eq $bar } $foo eq (lc) $bar $foo eq{lc} $bar None of those are like any existing syntax in Perl. The current way: lc($foo) eq lc($bar) seems fine in

Upscope (was Re: RFC 143)

2000-08-24 Thread John Porter
Nathan Torkington wrote: We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Perhaps this would work: a way to override (i.e. quash) the behavior that instantiates a new scope on entry to a lexical block,

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Dan Sugalski
At 11:33 AM 8/24/00 -0600, Tom Christiansen wrote: While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they

Re: Exception handling [Was: Re: Things to remove]

2000-08-24 Thread Glenn Linderman
"BSOD" = huh? Oh, Blue Screen of Death. Certainly if the OS doesn't support trapping an error, then the language running on it cannot either. But if the OS does, then the language could. If the language could, then the question remains whether it should, and that's a -language topic that

Re: OT: pronouncing www (was: Re: ... as a term)

2000-08-24 Thread Austin Hastings
"foo.bar" ne "www.foo.bar" pronounce("foo.bar") eq pronounce("www.foo.bar") As in, "Surf to www.perl.org and read the new ..." sounds like "Surf to perl dot org and read the new ..." =Austin --- Tom Christiansen [EMAIL PROTECTED] wrote: The "www" in e.g., "www.netscape.com" is pronounced,

Re: OT: pronouncing www (was: Re: ... as a term)

2000-08-24 Thread Ted Ashton
Thus it was written in the epistle of Austin Hastings, "foo.bar" ne "www.foo.bar" pronounce("foo.bar") eq pronounce("www.foo.bar") As in, "Surf to www.perl.org and read the new ..." sounds like "Surf to perl dot org and read the new ..." =Austin Just to be absolutely certain,

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Jarkko Hietaniemi
On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote: On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. Next you'll want

Re: RFC 151 (v1) Merge C$!, C$^E, and C$@

2000-08-24 Thread Bart Lateur
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: Merge C$!, C$^E, and C$@ Merging $! and $^E makes perfect sense to me. I don't know why there are two different error variables. Er... wasn't that three? I'm not absolutely certain, but I thought there was a third one, too. time

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread John Porter
Bart Lateur wrote: Suppose you want to keep the case on the hash keys, because you enumerate them. But you still want to find hash entries in a case insensitive manner... ...then you simply reach for Tie::CPHash on CPAN! -- John Porter

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

2000-08-24 Thread Bart Lateur
On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote: Damian Conway's Text::Balanced module does a pretty good job of tokenizing Perl code. However, bare C/.../ and C?...? require semantic analyis to distinguish them from division and the hook (CA?B:C) operator. To remove this hassle, and

Re: RFC 151 (v1) Merge C$!, C$^E, and C$@

2000-08-24 Thread Peter Scott
At 10:37 PM 8/24/00 +0200, Bart Lateur wrote: On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: Merge C$!, C$^E, and C$@ Merging $! and $^E makes perfect sense to me. I don't know why there are two different error variables. $! eq "No such file or directory"; $^E eq "CD-ROM drive

Re: RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.

2000-08-24 Thread Bart Lateur
On 24 Aug 2000 20:29:21 -, Perl6 RFC Librarian wrote: Replace first match function (C?...?) with a flag to the match command. Sounds reasonable. I propose "1". ?foo? becomes /foo/1 Eh, no, that looks silly. And, what's so special about the first match?

Re: RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.

2000-08-24 Thread John Porter
Bart Lateur wrote: And, what's so special about the first match? What if I want the second match, or the third? (/foo/g)[2] ??? -- John Porter We're building the house of the future together.

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

2000-08-24 Thread Nathan Wiger
Tom Christiansen wrote: You pretend that a reference is not a "true" scalar. That's certainly not valid. It obviously is. Well, this is a matter of semantics, pure and simple. Technically, it is. But I would argue that cognitively it is not by any means. Especially if a reference points to

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Peter Scott
At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote: Okay, devil's advocate. Paragraphs. sub legal { print FOO Attention criminal slacker, we have yet to receive payment for our legal services. Love and kisses FOO } I'm

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

2000-08-24 Thread Tom Christiansen
However, consider this in a different light for a moment: $a = "MyClass"; *a = MyClass-generate; # ask for ref back $a-blah; *a-blah; # use our ref Whether or not having to care about your refs is good or bad depends on which way you look at it. In one case, it's

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Tom Christiansen
I'm coming into this a bit late, so forgive me if this is impossible or already dismissed, but what about print qr/\s*FOO\s*/ Attention, dropsied weasel, we are launching our team of legal beagles straight for your scrofulous crotch.

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Peter Scott
At 04:30 PM 8/24/00 -0600, Tom Christiansen wrote: I'm coming into this a bit late, so forgive me if this is impossible or already dismissed, but what about print qr/\s*FOO\s*/ Attention, dropsied weasel, we are launching our team of legal beagles

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

2000-08-24 Thread Steve Fink
Tom Christiansen wrote: I happen to strongly appreciate that the invocant in $a-blah can be of either sort; that is: $a = "MyClass"; $a-blah; or $a = MyClass-generate(); $a-blah(); In fact, who knows what generate() returned? It could have been a class

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Peter Scott
At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; | Attention criminal slacker, we have yet | to receive payment for our legal

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Michael Fowler
On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; | Attention criminal slacker, we have yet | to receive payment for our legal services.

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Michael Fowler
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; Others may be focussing on the problem

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Bryan C . Warnock
On Thu, 24 Aug 2000, Nathan Torkington wrote: You'd obviously want to have a module that collected together your favourite new operators. But if they were lexically scoped, they'd be lexically scoped to the module they were defined in, i.e. your collection rather than your main program.

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Nathan Torkington
Dan Sugalski writes: Personally I think I'm in favor of Nat's suggestion of allowing the definition of new infix operators and let this be taken care of in a module, but that's just passing the buck. (Not that it's a bad strategy, mind... :) Solve the generic problem, not a specific one.

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

2000-08-24 Thread Nathan Torkington
Bart Lateur writes: Oh. I would have put my hopes on a better (= more generic) O::Deparse mechanism to make Perl analyse the source code for you. Rewriting a Perl in a module seems a bit silly to me. I don't know enough swear words to say how much I fucking hate the stupid braindead dumbfuck

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Tom Christiansen
Unfortunately the quoting on the terminator following decides the type of interpolation; we're missing a way of indicating how to recognize the terminator other than an exact match. If we say that /\s*FOO\s*/ means terminate on a line matching that pattern, then how can we also say whether

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Nathan Wiger
I was sorta going under the assumption that would cause leading and trailing whitespace to be ignored (not stripped) when looking for the end-of-here-doc indicator. Because whitespace is ignored, I was then proposing some new syntax for stripping whatever one likes from the contents of the

User-defined quoting operators

2000-08-24 Thread Peter Scott
A while ago on p5p Joseph Hall allowed as how he would like to have core support for SQL via a construct like qs/SELECT * FROM s_emp WHERE empno IN (101, 343, 573)/ I suggested that one would need to know what database handle it was acting on, and that what made sense (to me) was to

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Chaim Frenkel
I'm missing what you are trying to say. Are you suggesting that $foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ? I wasn't suggesting going that far. Just a little more DWIM. So that ($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef #

RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

2000-08-24 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: August 20, 2000 Last Modified: August 24, 2000 Version: 2

RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.

2000-08-24 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace first match function (C?...?) with a flag to the match command. =head1 VERSION Maintainer: Stephen P. Potter [EMAIL PROTECTED] Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Jarkko Hietaniemi
I want four special new comparison operators. Firstly, " e q " That is, an operator that ignores any leading, any trailing, and treats all intraspace as equivalent. If the embedded space is confusing, I may consider suggesting an operator modifier, "/ ". Secondly, Eq, which

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Dan Sugalski
At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Nick Ing-Simmons
Dan Sugalski [EMAIL PROTECTED] writes: At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-24 Thread Tom Christiansen
Case ignoring eq and cmp operators =head2 Problems with current ways to do it Perl currently knows basically two methods for checking of equality of strings case-insensitively: uc($a) eq uc($b) $a =~ /^$b$/i and for comparing them one: uc($a) cmp uc($b) The probably worst about these

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Chaim Frenkel
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Dan Sugalski writes: LW : And do we want to consider making this (and its ilk) Do The Right Thing? LW : LW :(@foo, @bar) = (@bar, @foo); LW We certainly want to consider it, though perhaps not in -internals. LW You can talk about passing

Re: RFC 127 (v1) Sane resolution to large function returns

2000-08-24 Thread Larry Wall
Chaim Frenkel writes: : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar : LW context, as long as the object returned overloads itself to behave as : LW arrays and hashes currently do in scalar context. : : Isn't this an internals issue? Not completely. The scalar

Re: RFC 151 (v1) Merge C$!, C$^E, and C$@

2000-08-24 Thread Bart Lateur
On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote: But $@ is an entirley different beast. The proposal is that $! would be overwritten with the die string. Reason: whoever's interested in both $@ and $! at the end of an eval? There was an error; everyone looks at $@, which almost

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Michael Fowler
On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote: I thought this problem would've been neatly solved by my proposed: print "FOO" =~ s/^ {8}//; Attention criminal slacker, we have yet to receive payment for our legal services. Love

Re: RFC 111 (v1) Whitespace and Here Docs

2000-08-24 Thread Tom Christiansen
Basically, it's shorthand for the current syntax: $message = "EOF" =~ s/^\s*\| ?//g; | Attention criminal slacker, we have yet | to receive payment for our legal services. | | Love and kisses | EOF print $message; But any