Typeglobs, filehandles, asterisks

nts like "local *FH") and I don't see how it breaks backward compatibility any more than would happen if typeglobs get the axe. -- Peter Scott Pacific Systems Design Technologies

RE: type-checking [Was: What is Perl?]

.. Perhaps the best of both worlds would be design-by-contract? A la Conway? -- Peter Scott Pacific Systems Design Technologies

Re: type-checking [Was: What is Perl?]

At 11:08 PM 8/1/00 -0400, Chaim Frenkel wrote: > >>>>> "PS" == Peter Scott <[EMAIL PROTECTED]> writes: > >PS> Perhaps the best of both worlds would be design-by-contract? A la Conway? > >Conway? Who's Conway? http://www.csse.monash.edu.a

Re: RFC: lexical variables made default

ur Keep 'em short. As for making lexicals the default, I ain't giving up the typo-catching effect of use strict 'vars'. So you'd need something like use strict 'declarations' which would require all variables to be declared with one of the above three before first use (or be package-qualified). -- Peter Scott Pacific Systems Design Technologies

RFC: Filehandle type-defining punctuation

Hearing no outright derision in response to my trial balloon, here it is as an RFC: =head1 TITLE Filehandles should use C<*> as a type prefix if typeglobs are eliminated. =head1 VERSION Maintainer: Peter Scott <[EMAIL PROTECTED]> Date: 2 Aug 2000 Version: 1 Mailing

Re: multiline comments

At 02:53 PM 8/2/00 -0400, John Porter wrote: >Perhaps a better way would be a change in the semantics of scalar >literals in void context, to be silently ignored. No! It's a major typo/bug-catcher. -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Filehandle type-defining punctuation

rated by a divider. Never seen this interpretation before, though.) -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Filehandle type-defining punctuation

At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote: >ref() has always been a de facto typeof operator, no? > > open my $fh, "< /etc/motd"; > print ref $fh >GLOB Can we make that IO in P6...? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Filehandle type-defining punctuation

h = open $filename or die "open $filename failed: $!\n"; -- Peter Scott Pacific Systems Design Technologies

Where must you 'no strict'?

$ref = "foo"; print $$ref? Could Perl distinguish these two types of operation so that the former would not be a strict violation? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Modify open() and opendir() to return handles

tions to throw exceptions rather than set $!. Still need a global variable for that... -- Peter Scott Pacific Systems Design Technologies

Re: wanthash

g anyone else has come up with so far :-) Dunno why he hasn't mentioned it himself yet; probably too busy writing Lingua::RFC to do his submissions for him and B::RFC2C to implement them :-) -- Peter Scott Pacific Systems Design Technologies

Re: perl 6 requirements

ust need to put that -w in :-) $ perl -Mstrict -we 'sub foo {print ("This stuff gets"," printed", "\n"), return 3 if 1}' print (...) interpreted as function at -e line 1. $ perl -Mstrict -e 'sub foo {print ("This stuff gets"," printed", "\n"), return 3 if 1}' $ -- Peter Scott Pacific Systems Design Technologies

Re: Recording what we decided *not* to do, and why

*don't* want to perpetuate? Is it worth separating into a mailing list, a thread on this list, an RFC, none of the above? -- Peter Scott Pacific Systems Design Technologies

Stackable ties

IxHash at the same time. The code to handle this at present is... interesting. Is it at all possible to define interfaces for tie-ing that would facilitate stacking? Do we care? -- Peter Scott Pacific Systems Design Technologies

Re: proto-rfc. Elements of @_ should be read-only.

espect (user subs being able to do anything builtins can) rather than less. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 17 (v1) Organization and Rationalization of Perl

st have the merit of i18n :-) I don't see any "use French" scripts out there yet... Aside from that, though, there is the virtue of rationalization in the English proposal... plus never having to worry about this: http://www.segfault.org/story.phtml?mode=2&id=3905b40e-05c0a760 :-) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 16 (v1) Keep default Perl free of constraints su

he shebang line and nothing in one-liners. -- Peter Scott Pacific Systems Design Technologies

Re: New Group proposed: subs (was Re: named parameters)

; 'this'; > >or something along those lines -- since it's currently up to the devleoper >anyway. Somethign about a capitolized SELF is unappealing to my eyes. Agreed. It also looks wrong to use all caps for a lexical rather than a package global. -- Peter Scott Pacific Systems Design Technologies

Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)

oth mechanisms a la Fatal.pm looks attractive. Having structured exception objects so you don't have to roll your own regexen parsing $@ is also very important... oops, better save it for the new list... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 16 (v1) Keep default Perl free of constraints su

way they go about things, but if we can give them something that doesn't hurt everyone else then it's a win. At least by the "Big House" philosophy. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 34 (v1) Angle brackets should not be used for fi

way." No "Let's put both in, wait a while, and take out the one that gets used the least." O, wonder! How many goodly creatures are there here! How beauteous mankind is! O brave new world, That has such people in't! --- Miranda (The Tempest, V(i)) -- Peter Scott Pacific Systems Design Technologies

@a = @b || @c

rt of a larger issue I haven't seen? -- Peter Scott Pacific Systems Design Technologies

Deep copy

Another one for my wish list: deep copying support built in. A devil inside me thinks this should be a new assignment operator. Damian? Sounds like this is up your alley. I want to do a sanity check before taking up RFC space. -- Peter Scott Pacific Systems Design Technologies

Re: @a = @b || @c

At 01:15 PM 8/6/00 +0200, Johan Vromans wrote: >Peter Scott <[EMAIL PROTECTED]> writes: > > > @a = @b || @c should 'work'. In P5 it puts @b in scalar context and > > thus evaluates as the number of elements in @b if there are any. > >Define 'work'

Re: Deep copy

. > >That's cool. I can also see calling a package's CLONE sub if you're >cloning something blessed into it. Presumably it'd get the original as a >parameter and return the new thing, or something of the sort. I *really* like this idea. There should also be a defa

Re: RFC 49 (v1) Objects should have builtin string SCALA

object tells the difference between being in scalar context and being in string context. Call me old-fashioned, but I don't see what's wrong with use overload '""' => sub { $_[0]->to_string }; for anything that wants to take such a relatively odd action. -- Peter Scott Pacific Systems Design Technologies

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

for some people, on the screen) from plain _. Not that they won't be able to tell by looking harder and seeing the context, but the potential for a higher casual misunderstanding is there. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 49 (v1) Objects should have builtin string SCALA

Which one should win? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Rename local() operator

quot; isn't a verb and I think we need a verb er ... here. >Granted, "local" isn't a verb either, but that's probably part of it's >problem. Dang, just make it a pragma and let the user pick the word they want: use thingy (qw(save hide shadow here there plugh hold cut rinse plonk))[rand 10]; :-) -- Peter Scott Pacific Systems Design Technologies

Re: Treating filehandles like strings

ation is to harden scripts against DoS attacks with endless inputs filling up the memory buffers while still allowing programmer to use <>. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote: > sub *BEGIN { ... } > sub *END{ ... } > sub *INIT { ... } > sub *AUTOLOAD { ... } > sub *TIESCALAR { ... } > sub *FETCH { ... } Only half of those a

RE: Deep copy

I don't think it's impossible to do something useful, if we think sufficiently Perlish. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 54 (v1) Operators: Polymorphic comparisons

the number to a string and do a stringwise eq in this case? -- Peter Scott Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

sub _TIESCALAR {} >sub _FETCH {} >sub _STORE {} >sub _DESTROY {} If you're going to use a convention, rather than a syntax, then the current convention of all CAPS reserved to Perl is easier to understand, more pleasing to the eye, and backwards compatible. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote: >On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote: > > At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote: > > > sub *BEGIN { ... } > > > sub *END{ ..

ISA number

we have enough creativity here I'm sure we can come up with something far more obfusc^Wconcise :-) -- Peter Scott Pacific Systems Design Technologies

Re: ISA number

At 08:31 PM 8/7/00 +0100, Hildo Biersma wrote: >Peter Scott wrote: > > > > Have often wanted a way to tell whether a scalar was a number, and rolling > > a regex each time seemed wasteful given that Perl knew what it was > > anyway. So a user-friendly way to get at

Re: RFC 55 (v1) Compilation: Remove requirement for fina

realistic case you want to catch is an empty file, why not just check for that and issue an error? Easier than everyone in the world having to stick 1; at the end of their .pm (who's forgotten it, now? Hands up...) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > >I meant that BEGIN, END, and INIT aren't declared as subs at present but > >named blocks. I was surprised to discover that they're put in the symbol > >tabl

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

"placeholder". > > >Yes, it's been suggested, but we might be too late on that one--another RFC >suggests reserving '*' for reserved perl identifiers. Lord no - there's nothing wrong with contradictory RFCs. These are just ideas, we're not making the decisions here. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

At 09:28 AM 8/8/00 +0100, Piers Cawley wrote: >Peter Scott <[EMAIL PROTECTED]> writes: > > > At 12:07 AM 8/8/00 +0200, Bart Lateur wrote: > > >On Mon, 07 Aug 2000 10:56:40 -0700, Peter Scott wrote: > > > > > > >I meant that BEGIN, END, and INIT are

RE: Error handling

;} > This is being hashed out on per6-language-flow right now... -- Peter Scott Pacific Systems Design Technologies

Re: sub optional for BEGIN: bad idea

ecuted, I'll leave that for another day... $ perl -le 'BEGIN{print"Fie!"}print $::{BEGIN}' Fie! *main::BEGIN -- Peter Scott Pacific Systems Design Technologies

Re: default $/ (was Re: RFC: println())

27;t have private $/. > >i like the ability to set global defaults here. If filehandles are objects, then they live in classes which could inherit from UNIVERSAL, no? -- Peter Scott Pacific Systems Design Technologies

RE: RFC 67 (v1) Deep Copying, aka, cloning around.

complicated than a special >case of the above dcopy subroutine? Nope, it would indeed call that subroutine and not much else. But I think dcopy/clone will end up being an internal, not Perl code. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 67 (v1) Deep Copying, aka, cloning around.

nternally (by someone else :-). But if it gets complicated to express certain aspects of the algorithm it may be handy to use the Perl version as pseudo-code to establish the intent of the RFC. -- Peter Scott Pacific Systems Design Technologies

Re: Error handling

as you want; brainstorm, get wacky. Ultimately every idea will go through Larry & Co and I trust his/their judgement to use whatever looks good and ditch the rest, however popular. I do not want a language designed by a committee, or even a democracy. This is art, not politics. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 23 (v2) Higher order functions

>=head1 TITLE > >Higher order functions Well, this should keep the Obfuscated Perl Contest going for at least another decade :-) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 73 (v1) All Perl core functions should return ob

own: $result = chown $uid, @dirs; print "Failed for these dirs: ", $result->failures; print "Failure reasons: ", map $_->failure_reason, $result->failures; But IMHO that word 'all' puts a stake in its heart. Each system function should be evaluated on its own merits. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 73 (v1) All Perl core functions should return ob

At 12:09 PM 8/9/00 -0600, Nathan Torkington wrote: >stat, sockets, messaging, and the rest of the advanced stuff should >probably go to modules. Yes, plus the get* functions. Do we need an RFC on this? -- Peter Scott Pacific Systems Design Technologies

Re: Overloading && ||

. This is too venerable a semantic to change. Please. -- Peter Scott Pacific Systems Design Technologies

Re: Overloading && ||

ften wondered whether a language could allow user-defined operators. The fact that none have done it should be a clue :-) I guess it's getting too incestuous with the lexer. -- Peter Scott Pacific Systems Design Technologies

Re: Overloading && ||

At 07:45 PM 8/9/00 +, Nick Ing-Simmons wrote: >Peter Scott <[EMAIL PROTECTED]> writes: > >At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote: > >>While I remember - it would be good if overload mechansim > >>could be extended to cover && and || as well

Re: RFC 80 (v1): Exception objects and classes for builtins

At 02:56 AM 8/10/00 -0500, Jonathan Scott Duff wrote: >Peter Scott writes: > > try { > > # fragile code > > } catch Exception::IO with { > > # handle IO exceptions > > } catch Exception::Socket with { > > # handle

Re: Portable upper/lower case regexp matches

a digraph. Question is, which one? Currently the free ones are: \F \h \H \i \I \j \J \k \K \m \M \o \O \q \R \T \v \V \y \Y \v \V are being debated on p5p currently. I suggest \i \I, mnemonic with ?:i and /i. I know it's a strange association once you think about it, but it made sense at first thought. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1) Exception objects and classes for builti

s, etc). RFC 70 wants all these to be turned into optional exceptions if Fatal is used. Exceptions: the builtin die()s. RFC 80 was actually only thinking about these, but clearly gets even more power if Fatal is used, when a whole bunch more exception classes come into play. I like the way this is going. I'll fix up v2. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

nsiderably more appealing, especially since catch blocks can contain tens of statements. It's easier to see the exception class (not tucked inside a method call), and there aren't additional block levels. BTW, the methods in Error.pm I don't use are except() and record(). -- Peter Scott Pacific Systems Design Technologies

Re: RFC 85 (v1) All perl generated errors should have a

cess violation :-) >=head2 Classification Schemes > >To be defined. Suggestions welcome. I made a start in RFC 80. -- Peter Scott Pacific Systems Design Technologies

Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

At 02:39 PM 8/10/00 -0500, Jarkko Hietaniemi wrote: >There are quarter-hour time zones... And then there's Damian, who lives in a non-linear time zone... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1) Exception objects and classes for builti

# handle other exceptions > }; > >And it would look silly to use "otherwise" there. > >You could make it so "catch" takes a list of 0 or more exception >class names. I like this. I will modify RFC 63 accordingly, although I note that RFC 88 is proposing something extremely similar. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

en (example: C operator precedence). But one could argue at this point that Perl's gravitational pull is now sufficient for it to borrow from itself rather than other languages, as you have done above. I just found the try/throw/catch syntax really appealing, and it was a bonus that it woul

Re: RFC 80 (v1): Exception objects and classes for builtins

yword, but later wished he had. I couldn't find this, and the current docs give no hint of remorse, so it could all be a scurrilous figment of my imagination. It appears that the majority favors eval, though... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

n of travel :-) In both cases you don't know where you're going to land. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

of the last block; it's only needed at the moment because eval is a function, not a keyword. I would vote for the keywords only because people are going to forget the ; otherwise. I like reusing 'continue' since I use 'finally' blocks about as often as I use 'continue' blocks anyway :-) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

que to >=>. You >could just as well say > > bareword, $whatever > >and get the same effect in perl5! Have you used strict lately? :-) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 85 (v1) All perl generated errors should have a

red along the lines needed by warnings and I see a poor match for run-time exceptions. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 80 (v1): Exception objects and classes for builtins

atch an exception, semantically, it hasn't been caught, so why would you need to explicitly rethrow it? If the implementation needs to catch it anyway, that's the implementation's problem. -- Peter Scott Pacific Systems Design Technologies

Re: errors and their keywords and where catch can return to and stuff like that

It probably should have been optional for the exception to have been thrown in the first place. -- Peter Scott Pacific Systems Design Technologies

Re: command line option: $|++

is issue speak to it? Will $| $/ $\ et al be retired, or be valid for some default filehandle? Will there still be default filehandles? Will there be a way of altering the line discipline characteristics or whatever they're called globally? If so, how? Any plans as yet for changing t

Re: command line option: $|++

At 11:35 AM 8/15/00 -0700, Nathan Wiger wrote: >Peter Scott wrote: > > > > Can someone knowledgeable on this issue speak to it? > > > > Will $| $/ $\ et al be retired, or be valid for some default filehandle? > > > > Will there still be default filehandles?

Re: English language basis for "throw"

At 05:06 PM 8/15/00 -0400, John Porter wrote: >I think about the word some OO gurus use: "raise". I think that came from the kernel or hardware people before OO was around. Something about raising and lowering IPLs. -- Peter Scott Pacific Systems Design Technologies

Re: English language basis for "throw"

n; }, > ebola => { overrule; }, > { punt; } > } > } What interpretation should be placed on statements in the try block following a catch block? -- Peter Scott Pacific Systems Design Technologies

Re: RFC 109 (v1) Less line noise - let's get rid of @%

name >and disambiguates nicely. I'd be very upset if this idiom went away. What he said. Several things have occasionally struck me as standing improvement in Perl; this has never been one of them. It's always been very intuitive and easy to understand for me. Methinks the l

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

taining \n inside single quotes just 'cuz it didn't contain variables to be interpolated. Whether there's a way of improving this behavior or not I don't know. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote: > > No, neither proposal makes sense. Arrays can be stored compactly and > >$a[1_000_000_000] = 'oh, really?' # :-) Now, now, there have been credible proposals for sparse arrays, you know that... -- Peter Scott

Re: Default filehandles(was Re: command line option: $|++)

e options that change the line characteristics for STDOUT and STDIN, which is what it boils down to. While you're at it, mebbe you could come up with something better than @F for -a :-) -- Peter Scott Pacific Systems Design Technologies

Re: RFC 82 (listops in list context)

* distributive would be something written on a bathroom wall at Venice beach. In between we have @a = @b || @c; which goes according to taste. Mebbe a slightly cleaned-up version of Flesh Gordon (which has been airing on the Space Channel in Canada, but would never see the light of day on the equivalent cable tier in the US). -- Peter Scott Pacific Systems Design Technologies

Re: RFC 68 (v1) Eliminate the optional C for C

don't act like normal subroutines). -- Peter Scott Pacific Systems Design Technologies

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

verywhere. And even if it were >why should any other program use the same epoch. > >The only valid interchange would be to specify the date unambiguously, >for example the ISO MMDDHHMMSS.fff ISO 8601. http://www.cl.cam.ac.uk/~mgk25/iso-time.html -- Peter Scott Pacific Systems Design Technologies

Re: RFC 114 (v1) Perl resource configuration

re resolved? Let's not start down that path. -- Peter Scott Pacific Systems Design Technologies

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

drag on forever they may turn ugly. Besides, the -internals folk are waiting to see what they need to get going on. And I would think we'd want a time when we knew Larry could get going on the RFCs without wondering whether something else was going to romp out of the starting gate. -- Peter Scott Pacific Systems Design Technologies

$!

t I thought I'd shake the branches anyway and see what fell out. I'm sending this to -language because folk are probably expecting just exception stuff on -errors; but I think it would be best for respondents to redirect to -errors. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 126 (v1) Ensuring Perl's object-oriented future

At 05:12 AM 8/19/00 +1000, Damian Conway wrote: >> The main downside of accessors is that you can't (currently) say >> >> local $obj->attribute = 2; > >Even if C returns an lvalue??? If it does, how do you localize it? What would that mean? -- Pe

Maximum length input lines

like read(). Would really like a feature that said, "<> will get characters until this many have been retrieved, or newline, whichever comes first." Sound reasonable? -- Peter Scott Pacific Systems Design Technologies

Re: Maximum length input lines

f someone throws a gargantuan number of characters at FH without a newline. The $/ = ref_to_int feature is exactly the kind of feature I was expecting to do this and I was disappointed that it didn't. -- Peter Scott Pacific Systems Design Technologies

Re: Maximum length input line

han that would be an error of some kind." Yes, Perl can handle many more characters than that before it starts to have problems, but so what. Maybe I have scripts where I would set it to 1_000_000_000 but that would still make sense. [followups to -io only please] -- Peter Scott Pacific Systems Design Technologies

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

ng etc Yes, this is losing information; the former $! is no longer around. I contend that it's eliding functionality that is seldom, if ever, used, in favor of a natural simplification. There's one place where an error message shows up. One. No need to figure out what kind of thing failed. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 111 (v1) Whitespace and Here Docs

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

Re: RFC 111 (v1) Whitespace and Here Docs

ng our team of legal beagles > straight for your scrofulous crotch. > > xx oo > FOO > >you mean? Right; I was proposing new syntax for recognizing the terminator; it would not have any effect on the intervening text. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 111 (v1) Whitespace and Here Docs

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 s

User-defined quoting operators

ined q[a-z]// (using a letter that hadn't already been taken), where you get to specify the actions of =~ and probably more operators? Sounds like it has a lot in common with operator overloading - maybe even just an extension to overload.pm? -- Peter Scott Pacific Systems Design Technologies

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

At 11:32 AM 8/25/00 +0200, Johan Vromans wrote: >Nathan Torkington <[EMAIL PROTECTED]> writes: > > > Read my lips: GOOD THING. > >Do we have an RFC yet that proposes Perl to be easier parsable? We have one proposing nearly the opposite: RFC 28. -- Peter Scott Pacific Systems Design Technologies

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

addressed is table 3-3 on p. 97 of Camel III (unlabelled table on p. 84 of Camel II)? -- Peter Scott Pacific Systems Design Technologies

Re: I'll try once more..

kes the copying easier to spot since it's up front and you don't have to scan to the end to discover it. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 45 (v1) || should propagate result context to bo

te to the irony and it will simply appear more consistent. If anyone has written a subroutine that does such different things in each context that it would be broken by this, well, I would like to see that code and ask them a few questions... -- Peter Scott Pacific Systems Design Technologies

Re: RFC 45 (v1) || should propagate result context to bo

n by this sentence). > > =head1 REFERENCES > > > > L > >What about Damian's want (RFC 21) Yes, thanks. -- Peter Scott Pacific Systems Design Technologies

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

he same way in Perl 6 as it does now, so you will indeed be able to do what you propose. (This is my position and RFC 88's position, but there are disagreements.) (Nearly) everrrybuddy heppy :-) -- Peter Scott Pacific Systems Design Technologies

Multiple for loop variables

ether this construct would really give the parser problems or whether looking ahead for the block will disambiguate. Unfortunate that (I assume that) it couldn't extend to the modifier form as well. -- Peter Scott Pacific Systems Design Technologies

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

wholeheartedly support the RFC; but it opens a can of worms that should be addressed. Perhaps in another RFC. Do any other (Damian) RFCs on (Damian) prototyping impact (Damian) this area? -- Peter Scott Pacific Systems Design Technologies

  1   2   3   >