Re: pack/unpack is damn unperlish. Explain them as Perl.

anything wrong with the interface though, it seems quite appropriate. -- Peter Scott Pacific Systems Design Technologies

Re: Dual nature (was Re: Exceptions and Objects)

miles away. chaim "PS" == Peter Scott [EMAIL PROTECTED] writes: PS At 10:16 AM 8/16/00 -0400, Chaim Frenkel wrote: One issue that haven't seen addressed, is how to _not_ have exceptions. I want to use a core module (non-core can do anything they want) but I'd like to write i

Re: Towards a reasonable unwinding flow-control semantics.

At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote: "PS" == Peter Scott [EMAIL PROTECTED] writes: PS 1. When an exception is thrown perl looks for the enclosing try block; if PS there is none then program death ensues. Err, if there isn't one. Don't throw the exception. Stop processing

Re: Towards a reasonable unwinding flow-control semantics.

the next enclosing try block). This will happen if an exception was not caught, or if a catch or finally block threw an exception. I note that under these rules it would be possible to have "try { ... } finally { }" with no catch blocks. I guess that's okay. -- Peter Scott Pacific Systems Design Technologies

RE: warn (was: yoda 2)

the exception stack in @_. If we use the RFC 63/Error.pm idea of passing the current exception in $_[0], then this falls out naturally, and no need to follow a linked list. Gets my vote. -- Peter Scott Pacific Systems Design Technologies

Re: Draft 3 of RFC 88 version 2.

ds alright; there's something very self-defeating about raising a run-time exception from dying badly, if you see what I mean. So the third case goes and the second one becomes, args are stringified and joined on '', etc. -- Peter Scott Pacific Systems Design Technologies

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

At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote: Peter Scott wrote: I actually see nothing wrong in division returning undef for a dividend of 0. It's just as easy to check as doing an eval. Please don't do this. I would have to check every divide in all my code, since no fatal

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

that was: Any exception raised in a try will be fatal unless caught? It already is (RFC 88). -- Peter Scott Pacific Systems Design Technologies

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

. That's how Error.pm implemented it and it makes perfect sense. Nothing in RFC 88 precludes die and throw from sharing the same underlying code, or simlarly catch/eval. I think it should make it clear that they *are* the same thing. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 63 (v4) Exception handling syntax

probably has way too much time on their hands :-) -- Peter Scott Pacific Systems Design Technologies

Re: Why fatal errors aren't special.

" die. There are no existing fatal exceptions. You can call die as much as you want, but if your caller has wrapped you in an eval block, tough. RFC 88 does not change this at all. -- Peter Scott Pacific Systems Design Technologies

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

authors who wished to to automatically support this functionality as well. Got anything in mind? $^something? -- Peter Scott Pacific Systems Design Technologies

Re: Structured exception handling should be a core module.

be cleared if the eval doesn't fail, just like $@ is now. Yes. Basically, you can think of the new $! as getting done to it whatever was last done to any of the set of $@, $!, $^E, and $? in the current Perl. Well, I doubt it will be that simple :-) -- Peter Scott Pacific Systems Design Technologies

Re: Structured exception handling should be a core module.

At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote: Peter Scott wrote: If $@ and $! are merged, then in code like try { system_call_that_fails(); more_stuff_that_succeeds(); } finally { } does the finally block

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

Redirected to perl6-language-flow. At 12:23 PM 8/11/00 +0100, Graham Barr wrote: On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote: If we're really talking about new keywords, we wouldn't need a ; at the end of the last block; it's only needed at the moment because eval

Re: Exceptions and Objects

ferent classes, some of which have subclasses (a File error is-a IO error). Users want to define their own kinds while reusing the semantics of the base class. Bingo. -- Peter Scott Pacific Systems Design Technologies

Re: The distinction between do BLOCK while COND and EXPR while COND should go

the other weird uses of 'do', yes... -- Peter Scott Pacific Systems Design Technologies

Re: The distinction between do BLOCK while COND and EXPR while COND should go

in a do block whose value is used by something should be a syntax error. We're talking about code like $x += do { $y = get_num; last if $y == 99; $y } while defined $y; right? *Shudder* -- Peter Scott Pacific Systems Design Technologies

Re: The distinction between do BLOCK while COND and EXPR while COND should go

: 7 Why don't I see three STOREs? and you're left with 7. -- Peter Scott Pacific Systems Design Technologies

Re: The distinction between do BLOCK while COND and EXPR while COND should go

gripe since I have no idea where to start simplifying. -- Peter Scott Pacific Systems Design Technologies

Re: A common event loop

the question I put to you all is, would it make sense for Perl to have a common event loop from which all other modules can then draw, thus avoiding the current state of conflict? Absolutely. The architecture of Tk applications will change considerably, for the better. -- Peter Scott Pacific Systems Design

Re: Warnings, strict, and CPAN

At 11:00 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote: On Fri, Feb 16, 2001 at 06:52:22PM -0800, Peter Scott wrote: S'not about saving keystrokes, as many times as I do type the same things in every file; it's about giving newbies the right introduction to the language and providing

Re: Warnings, strict, and CPAN

, its damned silly that you can't give two modules on the command line. ??? $ perl -Mwarnings -Mstrict -le 'print keys %INC' Exporter.pmCarp.pmstrict.pmwarnings.pm -- Peter Scott Pacific Systems Design Technologies

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

? A la Conway? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: lexical variables made default

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

Re: RFC: Filehandle type-defining punctuation

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

Where must you 'no strict'?

ot;; 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

l variable for that... -- Peter Scott Pacific Systems Design Technologies

Re: wanthash

Lingua::RFC to do his submissions for him and B::RFC2C to implement them :-) -- Peter Scott Pacific Systems Design Technologies

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

builtins can) rather than less. -- Peter Scott Pacific Systems Design Technologies

@a = @b || @c

issue I haven't seen? -- Peter Scott Pacific Systems Design Technologies

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

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: RFC 49 (v1) Objects should have builtin string SCALA

should win? -- Peter Scott Pacific Systems Design Technologies

Re: RFC: Rename local() operator

d 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

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

n 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{ ... } sub *INIT { ... } sub

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 table anyway though. Check the docs again

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

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 aren't declared as subs at present but named blocks. I

Re: sub optional for BEGIN: bad idea

.. $ perl -le 'BEGIN{print"Fie!"}print $::{BEGIN}' Fie! *main::BEGIN -- Peter Scott Pacific Systems Design Technologies

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

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.

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: Error handling

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: Overloading ||

-circuit happens. No. I don't want to see or || and not know whether it short-circuits without looking in the class interface. My brain is conditioned through years of C and Perl to expect that they always short-circuit. This is too venerable a semantic to change. Please. -- Peter Scott

Re: Overloading ||

. 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: 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 network exceptions } otherwise { # handle

Re: Portable upper/lower case regexp matches

\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

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: 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 builtins

) 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

, 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 85 (v1) All perl generated errors should have a

exceptions. -- Peter Scott Pacific Systems Design Technologies

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

, 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: command line option: $|++

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 the -0 and -l command line flags? -- Peter Scott Pacific

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

{ 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 @%

. 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 language list is starting to hit the ozone layer. -- Peter Scott Pacific Systems Design Technologies

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

ng digraphs I have often wished that digraphs were not bundled with variables in this respect, i.e., I wanted to put a string containing \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. -- Pe

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 Pacific Systems Design

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

ch 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)

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 Csub for CBEGI

into a different namespace (CORE:: or Perl:: or INTERNAL:: or whatever). My RFC initially started out that way, but reversed its sense after feedback before it got published. There are messages in the archives explaining why this should be so (they don't act like normal subroutines). -- Peter

Re: RFC 114 (v1) Perl resource configuration

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

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

ant 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

$!

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 151 (v1) Merge C$!, C$^E, and C$@

om, 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

. xx oo FOO -- Peter Scott Pacific Systems Design Technologies

Re: RFC 111 (v1) Whitespace and Here Docs

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

on a line matching that pattern, then how can we also say whether we want variable interpolation or not? Which is a pity, 'cos I kinda liked the idea :-) -- Peter Scott Pacific Systems Design Technologies

User-defined quoting operators

]// (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.

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

Re: I'll try once more..

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

What about Damian's want (RFC 21) Yes, thanks. -- Peter Scott Pacific Systems Design Technologies

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

(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

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

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

Re: Do we really need eq?

At 12:57 PM 8/29/00 -0500, David L. Nicol wrote: I'd like to see every number bundled with a "precision" attribute. It's a holdover from when I was heavily into chemistry. Some of the other RFCs on the list also appear to have been triggered the same way. Oh, wait... :-) -- P

Re: Beefier prototypes (was Re: Multiple for loop variables)

. Not to mention for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... } Probably we'll have to say that the user must explicitly zip if that is what is desired. Yes, please. I view the flattening of lists as a feature, not a bug, and it has made Perl a lot easier to understand IMHO. -- Peter Scott

Re: RFC 33 (v2) Eliminate bareword filehandles.

tense, just to pass filehandles around in scalars? -- Peter Scott Pacific Systems Design Technologies

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

? -- Peter Scott Pacific Systems Design Technologies

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

between the Cfor and the C(@list). Sorry, I missed/forgot that posting. I'll add it in. -- Peter Scott Pacific Systems Design Technologies

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

t any brilliant ideas before I withdraw it? -- Peter Scott Pacific Systems Design Technologies

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

'HASH' The subroutine was called in a context where its return value is assigned to (or treated as???) a hash: %hash = func(); @keys = keys func();# ??? -- Peter Scott Pacific Systems Design Technologies

Re: Proposal: chop() dropped

to a particular filehandle. Make sense? -- Peter Scott Pacific Systems Design Technologies

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

ip up even the wiley Antipodean Perl master (albeit in a chronically challenged state... so to speak). This is the kind of thing that keeps Perl instructors in business... -- Peter Scott Pacific Systems Design Technologies

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))

wonder how the p526 translator will handle this. Suppose someone deliberately did ($line) = FH; # Save next line, discard rest Maybe something like { ($line, my @plugh) = FH; } -- Peter Scott Pacific Systems Design Technologies

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))

At 10:52 AM 9/4/00 -0600, Nathan Torkington wrote: Peter Scott writes: ($a, $b, $c) = FH; or @a[4,1,5] = FH; only read three lines? I think this is a superb idea, and look forward to someone's RFC'ing it. Should be part of the want() context. It is. I

Re: RFC 33 (v2) Eliminate bareword filehandles.

ot; Accept-Ranges: bytes Content-Length: 9736 Connection: close Content-Type: text/plain I think it's time for a thread subject change. -- Peter Scott Pacific Systems Design Technologies

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

with something like this to get behavior like clone's, where the reult of a node depends on the results of other nodes? Whether they've been visited already or not, how do you parcel all the results of, say, a ref-to-array together? -- Peter Scott Pacific Systems Design Technologies

Re: Pre-RFC: undef =~ s/def/initialize/

for it, too. -- Peter Scott Pacific Systems Design Technologies

Re: $a in @b

overloading the one argument and say that if it's a reference, take the thing it refers to as the value and exit/continue the nearest enclosing loop. -- Peter Scott Pacific Systems Design Technologies

Re: $a in @b

keyword. $0.02. -- Peter Scott Pacific Systems Design Technologies

Re: $a in @b

a grep in the first place :-) -- Peter Scott Pacific Systems Design Technologies

Re: $a in @b

shouldn't be necessary to label a loop if you don't have another one inside it, although if you did, it would avoid the embarrassment of "last undef, 'foo'" that fell out of my suggestion. -- Peter Scott Pacific Systems Design Technologies

Re: Conversion of undef() to string user overridable for easy debugging

from easy debugging, this feature would hardly serve any other practical purpose. -- Peter Scott Pacific Systems Design Technologies

Re: Drop here docs altogether? (was Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs))

e doc" operator that solves these problems than trying to jam them all into the existing shell-like syntax, which is a leftover oddity, really. -- Peter Scott Pacific Systems Design Technologies

Re: RFC 241 (v1) Pseudo-hashes must die!

So can we keep the option for fixed keys somehow? -- Peter Scott Pacific Systems Design Technologies

  1   2   >