Re: Exception handling [Was: Re: Things to remove]
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 not at all clear that RFC 88 actually is proposing a feature called retry, that would do any sort of resume. To clarify, 88 is trying to say that it explicitly doesn't think it's a good idea to mix up the concept of exception handling with the concept of continuations, the latter of which is properly the domain of concepts like resume. (Pardon me sir, do you have a copy of your resume? Why yes, responds the Perl programmer, next.) Right. Not presently and against the concept. That's for continuations. So you just have a slightly different level of "fatal" than I do, and you have a slightly different level of "when do you need a separate mechanism" than I do. But in fact, you do consider there to be fatal error conditions that mechanisms proposed by RFC 88 should not handle. However, because you are enamored of past misuse of the fatal error mechanism to handle non-fatal errors, you want to perpetuate and build upon that misuse and continue to handle non-fatal errors via that mechanism, and include some, but not all, fatal errors, via that mechanism. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: Exception handling [Was: Re: Things to remove]
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" semantics. Sounds like good RFC fodder to me! Hi, it's me again. Not to be a pain, but RFC 88 does say: Hey, no pain. You know your RFC better than I do. Good thing, too. retry There has been some discussion on perl6-language-error about the concept of re-entering try blocks on catch, and the possibility of using such a mechanism to replace AUTOLOAD. The author is of the opinion that in order to do this sort of thing properly one should use continuations, which are being discussed elsewhere to this RFC. The intent of this RFC is to provide a simple yet robust exception handling mechanism that is suitable for error handling, not for replacing AUTOLOAD. 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 not at all clear that RFC 88 actually is proposing a feature called retry, that would do any sort of resume. If that was your intention, you need to add lots of beef to the "retry" method of the "Exception" class, or somewhere, to describe how to use it. When I read this quote, I thought it was just general discussion, and that that the remark about implementing retry "should use continuations" implied that this RFC was not (presently) including such a mechanism as part of it. s/retry/resume/g I agree that in this context they are synonyms. I'll try to make that more clear in 88v3d1. Right... is it part of the proposal, if so how does it work, what is the syntax for retrying, etc. Yours, c, Tony Olekshy -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: Exception handling [Was: Re: Things to remove]
"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 hasn't been discussed much. "David L. Nicol" wrote: i think he meant the windoes95 BSOD kind of GPF; that's how I read it at leas Glenn Linderman wrote: Dan Sugalski wrote: At 02:48 AM 8/24/00 +0200, Markus Peter wrote: --On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal errors, people that want to write fatal errors can switch to using "warn ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue firmly planted on cheek.] I can only hope this is pure irony... Indeed it was. There is no such thing as an ultimately fatal error - it should always be up to the user of a module wether the program should die, but I guess you see that the same and will answer me with "use eval" then ;-) I hope you're speaking from a perl level--a segfault pretty much spells "Game Over"... I have seen and worked on C++ code implementing a database system where database data was read into pages marked read-only, and then code was run. When attempts were made to write to the data, a segment fault was generated, the fault handler attempted to obtain a transaction lock on the data for that page. If it was successful, it marked the page writable and resumed from the fault. If it was unsuccessful in obtaining the lock, it marked the transaction "must be aborted", and threw a C++ exception out of the signal handler invoked by the segfault. 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" semantics. Sounds like good RFC fodder to me! One point of view might hold that "resume from hardware fault" would need only be implemented by a "fatal error handling" mechanism, and would not be necessary in a "non-fatal error handling" mechanism. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___ -- David Nicol 816.235.1187 [EMAIL PROTECTED] My argument is the result of selectively breeding straw men -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Things to remove
At 06:00 PM 8/21/00 -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : How about this then: : : In a void context, Cdump dumps the program's current opcode representation : to its filehandle argument (or STDOUT, by default). It's not clear to me that reusing a lame keyword for this is the highest design goal. Let's come up with a real interface, and then if we want to reuse the (the presumably missing) dump keyword for some method name or other, that's fine. But we're currently designing it from the wrong end. What I've been hoping for is: 1) The ability to dump the program and its current state out into something that can be reloaded later. (Though filehandles and other external-interface things make this tricky) 2) The ability to dump out a variable and all its attached state into something that can be loaded in later somewhere else. #1 is a natural outgrowth of bytecompiling a program--when you dump the bytecode, you have already executed module initialization code and BEGIN blocks, so that means variable dumps. #2 is because I want to be able to do: print SOME_SOCKET freeze_dry($an_obj) and have the other end do: my $remote_obj = reconstitute(scalar SOME_SOCKET); Or something like that, at least... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Things to remove
Dan Sugalski writes: : What I've been hoping for is: : : 1) The ability to dump the program and its current state out into something : that can be reloaded later. (Though filehandles and other : external-interface things make this tricky) : : 2) The ability to dump out a variable and all its attached state into : something that can be loaded in later somewhere else. Now all we have to do is make the program a variable, and the two requirements become one. Larry
Re: Things to remove
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print "I'll take a $name one, please, with @_.\n";
};
}
dump \@funx;
Closures will be challenging. :-)
--tom
Re: Things to remove
Tom Christiansen writes:
: 2) The ability to dump out a variable and all its attached state into
: something that can be loaded in later somewhere else.
:
: To hope to do this completely and correctly is courageous.
:
: my @funx = ();
: for my $name (qw/violet purple cream/) {
: push @funx, sub {
: print "I'll take a $name one, please, with @_.\n";
: };
: }
:
: dump \@funx;
:
: Closures will be challenging. :-)
Well, scratch it hard enough and you'll see that we're just discussing
persistent continuations.
Larry
Re: Things to remove
Tom Christiansen wrote:
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print "I'll take a $name one, please, with @_.\n";
};
}
snip
--tom
Or consider this pseudo code -
open file
lock file
dump file
file gets removed
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: Things to remove
At 11:32 AM 8/23/00 -0700, Larry Wall wrote:
Tom Christiansen writes:
: 2) The ability to dump out a variable and all its attached state into
: something that can be loaded in later somewhere else.
:
: To hope to do this completely and correctly is courageous.
:
: my @funx = ();
: for my $name (qw/violet purple cream/) {
: push @funx, sub {
: print "I'll take a $name one, please, with @_.\n";
: };
: }
:
: dump \@funx;
:
: Closures will be challenging. :-)
Well, scratch it hard enough and you'll see that we're just discussing
persistent continuations.
Yup. And, since the bytecode's going to have to have ways to list
variables, variable initializations, and lexical scope creation anyway,
it's not that big a deal. Dumping closures is actually relatively easy,
since they're mostly self-contained. (Assuming, of course, you ignore the
whole package variable and package subroutines thing... :)
AUTOLOAD for methods and symbolic refs are by far a bigger issue for a
comprehensive "Dump just what this object needs" thing.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Things to remove
At 03:47 PM 8/23/00 -0400, David Corbin wrote:
Tom Christiansen wrote:
2) The ability to dump out a variable and all its attached state into
something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print "I'll take a $name one, please, with @_.\n";
};
}
snip
--tom
Or consider this pseudo code -
open file
lock file
dump file
file gets removed
Yup. That falls into the whole "files and external things make this tricky"
category. Also applies to shared memory segments, database connections,
files in general...
There is no good guaranteed way to make this work. I'm all up for punting,
since presumably the programmer writing the code doing the freezing has
some clue as to what's going on.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Things to remove
On Wed, 23 Aug 2000, Buddha Buck wrote: Perhaps someone should RFC the new special variable ME, which is predefined to be the whole program. Who knows? Perhaps it would then make sense to use @_ at the top level, as if the program was invoked as "ME(@ARGV);"... Doesn't a lot of OO work (esp. on the Mac) tend to do this? The first thing they do in their application is instantiate an application (mainly, itself, without the application instantiation) and run it. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
Doesn't a lot of OO work (esp. on the Mac) tend to do this? The first thing they do in their application is instantiate an application (mainly, itself, without the application instantiation) and run it. That's right. All "pure" object-oriented languages work this way: the only object you instantiate directly is the "program object", whose CRun method you then call. H: print ref $0; # '/usr/damian/hm/demo.pl' print $0; # invoke stringization operator # to give serialized program state # (self-reproducing program) print $0+0; # invoke numerification operator # to give pid (retire $$) my $thread = $0-clone(); # threads $0-nice--; # accelerate program :-) Damian
Re: Things to remove
On Wed, 23 Aug 2000 17:24:23 -0600 (MDT), Nathan Torkington wrote: Compile the main() program code into a subroutine called 0, and you're off! 0 anyone? :-) (that's digit 0, by analogy to $0) What would be nice about this, is that then you could use "return" in a script to stop execution. I don't like "exit", because you can't trap it, if ever you wrap the code in another script. open OUT, "do.pl"; print OUT "exit\n"; close OUT; print "before\n"; do "do.pl"; print "after\n"; Or, "die" should have a way of stopping the program without a warning message. -- Bart.
Re: Exception handling [Was: Re: Things to remove]
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
firmly planted on cheek.]
I can only hope this is pure irony...
There is no such thing as an ultimately fatal error - it should always be
up to the user of a module wether the program should die, but I guess you
see that the same and will answer me with "use eval" then ;-)
and from another mail:
While nothing in RFC 88 precludes die and throw from sharing the same
underlying code, or similarly catch/eval, doing so isn't a good idea: it
forces people that want to use exceptions for non-fatal error handling to
suddenly have to also handle fatal errors as well.
In which way are they forced? You simply need not catch the fatal
exceptions.
try {
...
}
catch ! $@-fatal = { ... }
That might be a bit longer to type than eval { }; do_stuff_with($@) but I
think consistency in handling is more important here.
and another mail:
Once a (more appropriate than die) non-fatal throw/catch mechanism exists,
the use of die for non-fatal exceptions would hopefully wither away over
time... and if not, appropriate wrappers could be written.
I don't see why I should want that - sure, that's a way to cope with a
distinction between die and throw but without the distinction we simply do
not have the problem. And I definitely do NOT want to have a dozen wrapper
modules or whatever till that usage withered away in CPAN in 95% of the
modules after 1 year.
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Re: Exception handling [Was: Re: Things to remove]
At 02:48 AM 8/24/00 +0200, Markus Peter wrote: --On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal errors, people that want to write fatal errors can switch to using "warn ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue firmly planted on cheek.] I can only hope this is pure irony... There is no such thing as an ultimately fatal error - it should always be up to the user of a module wether the program should die, but I guess you see that the same and will answer me with "use eval" then ;-) I hope you're speaking from a perl level--a segfault pretty much spells "Game Over"... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Exception handling [Was: Re: Things to remove]
Dan Sugalski wrote:
Markus Peter wrote:
There is no such thing as an ultimately fatal error - it should
always be up to the user of a module wether the program should
die, but I guess you see that the same and will answer me with
"use eval" then ;-)
I hope you're speaking from a perl level--a segfault pretty much
spells "Game Over"...
Dan, FYI ~
Yes, from a Perl level.
In general, discussion on -errors have assumed that there will
be a class of what we are generically referring to as exceptions
that will indeed not behave according to the rules for all other
exceptions (such as being able to be caught by eval { ... } ).
Certainly segfault and hcffault (that's halt-and-catch-fire fault)
would we in that class of exceptions.
Other exceptions, such as out-of-memory, might almost be in that
class, except when the emergency out-of-memory memory pool comes
into play. I haven't though that one through.
Then there's exceptions like divide-by-zero and (if Cuse fatal; is
in scope) cant-open-file. Clearly, these are catchable. There is
currently a running dialogue on whether or not divide-by-zero and
other such so-called "fatal" errors should be handled by a separate
mechanism from that used for so-called "non-fatal" errors like
cant-open-file, where is where you stepped in. Said dialogue will
play itself out.
Yours, c, Tony Olekshy
Re: Exception handling [Was: Re: Things to remove]
Dan Sugalski wrote: At 02:48 AM 8/24/00 +0200, Markus Peter wrote: --On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote: Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal errors, people that want to write fatal errors can switch to using "warn ...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue firmly planted on cheek.] I can only hope this is pure irony... Indeed it was. There is no such thing as an ultimately fatal error - it should always be up to the user of a module wether the program should die, but I guess you see that the same and will answer me with "use eval" then ;-) I hope you're speaking from a perl level--a segfault pretty much spells "Game Over"... I have seen and worked on C++ code implementing a database system where database data was read into pages marked read-only, and then code was run. When attempts were made to write to the data, a segment fault was generated, the fault handler attempted to obtain a transaction lock on the data for that page. If it was successful, it marked the page writable and resumed from the fault. If it was unsuccessful in obtaining the lock, it marked the transaction "must be aborted", and threw a C++ exception out of the signal handler invoked by the segfault. 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" semantics. Sounds like good RFC fodder to me! One point of view might hold that "resume from hardware fault" would need only be implemented by a "fatal error handling" mechanism, and would not be necessary in a "non-fatal error handling" mechanism. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Exception handling [Was: Re: Things to remove]
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" semantics. Sounds like good RFC fodder to me! Hi, it's me again. Not to be a pain, but RFC 88 does say: retry There has been some discussion on perl6-language-error about the concept of re-entering try blocks on catch, and the possibility of using such a mechanism to replace AUTOLOAD. The author is of the opinion that in order to do this sort of thing properly one should use continuations, which are being discussed elsewhere to this RFC. The intent of this RFC is to provide a simple yet robust exception handling mechanism that is suitable for error handling, not for replacing AUTOLOAD. s/retry/resume/g I'll try to make that more clear in 88v3d1. Yours, c, Tony Olekshy
Re: Things to remove
Damian Conway wrote: Tom's opcode dumping functionality could, in principle, be added to Data::Dumper as it stands. My proposal was merely that CData::Dumper::Dumper body-snatch Cdump. But that's a crummy name for it, unix legacy not withstanding. Is someone working on an RFC? IIRC, it would propose that the entire state of the interpreter can be marshalled and unmarshalled, providing both a checkpointing capability and code mobility. Optionally the marshall will include only the explicitly given structures (subroutines, variables); or perhaps only a selected subset of interpreter state (code, data). -- John Porter We're building the house of the future together.
Re: Things to remove
Tom Christiansen wrote: Hmm, what about CHECK blocks? CHECK blocks would be great! But of course, they work in memory, which is not useful for persisting program state across executions, or moving it across machines. -- John Porter We're building the house of the future together.
Re: Things to remove
Here in my pre-caffiene morning trance it occurs to me that a few of the "fringe" features of perl should be removed from the langauge. Here's a few things that I would venture to say that none of the "perl5 is my first perl" people have probably ever actually used. reset # How often do you clear variables wholesale? dump study # never been a win for me. ?pattern? # one-time match split ?pat? # implicit split to @_ What's everyone's feeling on removing these from perl6? How often are they used? One could make dump "work" by having it dump out not a core or a.out, but rather the byte codes representing the current state of the perl machine. This seems anywhere from somewhat to seriously useful, and follows in the spirit of what dump was always meant to do. --tom
Re: Things to remove
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
From the Camel:
The C?? operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open words: $!\n";
while (DICT) {
$first = $1 if ?(^neur.*)?;
$last = $1 if /(^neur.*)/;
}
print $first,"\n"; # prints "neurad"
print $last,"\n"; # prints "neurypnology"
Nothing a SMOP can't address, but for one liners at the least, the
S part would seem to preclude the P part. (Same for the -l line-mode
flag.)
--tom
Re: Things to remove
Tom Christiansen writes:
: I've very rarely found cases where ?? was useful and // didn't work, and
: never in regular code.
:
: From the Camel:
:
: The C?? operator is most useful when an ordinary pattern match
: would find the last rather than the first occurrence:
:
: open DICT, "/usr/dict/words" or die "Can't open words: $!\n";
: while (DICT) {
: $first = $1 if ?(^neur.*)?;
: $last = $1 if /(^neur.*)/;
: }
: print $first,"\n"; # prints "neurad"
: print $last,"\n"; # prints "neurypnology"
:
: Nothing a SMOP can't address, but for one liners at the least, the
: S part would seem to preclude the P part.
I don't think the S and the P are that preclusive. For the example above
you can just say:
/(^neur.*)/ .. ""
If you want to be able to reset, then say
/(^neur.*)/ .. !$x++# reset with $x = 0;
Larry
Re: Things to remove
On Mon, 21 Aug 2000 06:11:02 -0600, Tom Christiansen wrote: $first = $1 if ?(^neur.*)?; $first ||= $1 if /(^neur.*)/; Now if only we had a shortcut operator which would continue only if the LHS was not defined... -- Bart.
RE: Things to remove
From: Damian Conway [mailto:[EMAIL PROTECTED]] One could make dump "work" by having it dump out not a core or a.out, but rather the byte codes representing the current state of the perl machine. This seems anywhere from somewhat to seriously useful, and follows in the spirit of what dump was always meant to do. I was contemplating suggesting that Data::Dumper be rolled into the core and take over Cdump. But I think I like this idea even more. It would be nice if a human readable dump were possible. So please don't completely dump the idea of Data::Dumper functionality in the core. Garrett
RE: Things to remove
One could make dump "work" by having it dump out not a core or a.out, but rather the byte codes representing the current state of the perl machine. This seems anywhere from somewhat to seriously useful, and follows in the spirit of what dump was always meant to do. I was contemplating suggesting that Data::Dumper be rolled into the core and take over Cdump. But I think I like this idea even more. It would be nice if a human readable dump were possible. So please don't completely dump the idea of Data::Dumper functionality in the core. How about this then: In a void context, Cdump dumps the program's current opcode representation to its filehandle argument (or STDOUT, by default). In a scalar or list context, Cdump dumps nothing, but rather returns the Isource code of its arguments (or of the current state of the entire program, by default). Thus: dump FILE; # dump program state as opcodes print FILE dump;# dump program state as source code print dump \%data; # dump contents of hash as source code print dump \@data; # dump contents of array as source code print dump \data; # dump subroutine as source code # etc. If people like this, would someone please RFC it. Damian
Re: Things to remove
Instant program migration:
host-a:foo.pl: print SOCKET dump;
host-b:bar.pl: { local $/; eval SOCKET };
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die; dump $fh }
sub resume { do $_[0] }
Damian
Re: Things to remove
Damian Conway writes:
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die; dump $fh }
sub resume { do $_[0] }
This is trickier than it first apperas, as the existing bytecode
shows. A Perl program is opcode + variables. Are you dumping symbol
tables? When recreated, will the variables have the same values they
currently do?
Just a pointer for the eventual RFCer to address.
Nat
Re: Things to remove
It would be nice if a human readable dump were possible. So please don't completely dump the idea of Data::Dumper functionality in the core. These are different things. And the bytecodes can always be B::Deparse'd, or whatever we come up with for uncompilation. Not that proper marshalling isn't seriously desirable as part of the standard distribtion. It's the basis for several important technologies, including data persistence and interprocess communication of the same. --tom
Re: Things to remove
dump FILE; # dump program state as opcodes You don't like that that should be a checkpoint resurrection at the point in the programmer labelled with "FILE:", per the current (semi-dis-)functionality? Hmm, what about CHECK blocks? --tom
Re: Things to remove
On Mon, Aug 21, 2000 at 03:43:44PM -0600, Tom Christiansen wrote: dump FILE; # dump program state as opcodes You don't like that that should be a checkpoint resurrection at the point in the programmer labelled with "FILE:", per the current (semi-dis-)functionality? Isn't that kinda lika yield; (the proposed coroutine "return") at the top level? Hmm, what about CHECK blocks? --tom -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Things to remove
: In a void context, Cdump dumps the program's current opcode : representation to its filehandle argument (or STDOUT, by : default). It's not clear to me that reusing a lame keyword for this is the highest design goal. Let's come up with a real interface, and then if we want to reuse the (the presumably missing) dump keyword for some method name or other, that's fine. But we're currently designing it from the wrong end. You're not a Sapir-Whorfist then? ;-) Actually, I wasn't proposing we design it at all. Sarathy has already done rather a good job of that, I think. Tom's opcode dumping functionality could, in principle, be added to Data::Dumper as it stands. My proposal was merely that CData::Dumper::Dumper body-snatch Cdump. Damian
Re: Things to remove
dump FILE; # dump program state as opcodes You don't like that that should be a checkpoint resurrection at the point in the programmer labelled with "FILE:", per the current (semi-dis-)functionality? Not much :-) Maybe: dump "FILE:" but not just a bareword :-( Hmm, what about CHECK blocks? Sorry, I'm a little slow today. You lost me. What about them? Damian
Re: Things to remove
On Sat, 5 Aug 2000 09:44:47 -0500, Jonathan Scott Duff wrote:
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How often do you clear variables wholesale?
Definitely. You can't even use it to clear a package, which would be one
of it's better uses. Grouping by start of name is a Bad Thing (TM), IMO.
Perlfunc says:
Generally used in a `continue' block at the end of a loop to
clear variables
Oi! Use block scoped lexical variables for that! Oh yes, this is pre
Perl5...
... and reset `??' searches so that they work again.
Now, that would have been interesting, if only ?PATTERN? itself was
worth bothering with. I've not ever used it. "last", anyone?
dump
Perlfunc says:
Primarily this is so that you can use the undump program
(not supplied) to turn your core dump into an executable binary
after having initialized all your variables at the beginning of
the program.
Only on Unix, I guess.
This function is now largely obsolete, partly because it's very
hard to convert a core file into an executable.
Not even there.
study # never been a win for me.
Me neither. I wouldn't know what it's good for. According to perlfunc,
it serves to speed up searches on a very large string. I don't do that
very often. Instead, I use lots of smallish strings, lines from a file.
?pattern? # one-time match
I've never used it. I never will. First, I like "last" to jump out of a
loop. Or you can set a variable in the match, like this:
$test ||= do { /PATTERN/ and ... };
There's also:
if($temp=(/PATTERN/ .. 0) and $temp==1) {
print "Hey!, got my first match!\n";
}
although that is a bit kludgy, not in the least because you can't
localize the temp.
split ?pat? # implicit split to @_
also:
split # in a scalar or void context
Dirty. Never ever. I'd rather have that in scalar context, split just
returned a count, without affecting @_.
I have a lot of suggestions of my own... but that will have to wait till
another post.
--
Bart.
Re: Things to remove
On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote: Perl++ perm -- good old hairy perl, finally under control. Running and ducking, --Steve
Re: Things to remove
The discussion of a new name for perl6 is amusing but irrelevant. It's not like this list doesn't get enough traffic already. Thanks for ceasing and desisting. Nat
Re: Things to remove
[EMAIL PROTECTED] writes: : Most of the requests for deletion seem to begin with, "This isn't : used..." : : To which, "*I* use it." is a very valid argument. : : Agreed. The real problem with ?...? is that it complicates the hell out : of the parser. So long as the special magic is retained for m?...?, I : would suggest that raw ?...? could beneficially disappear. Or turned into m//f, or some such. Must think about relationship to an extension-based reset operator as well. To maintain current semantics we'd need introspection into the regular expressions used in a particular package. Larry
Re: Things to remove
On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:
Someone proposed (I think I deleted that email) to make
while (FH) { ... }
work like
while (FH) { chomp; ... }
Guilty.
I've benchmarked the above codes, with '...' replaced by nothing, chomp
vs. the -l command line switch, and it turns out that the implicit chomp
of -l is almost 10% faster than the explicit chomp() of the traditional
approach: 9.83 seconds (implicit) vs. 10.77 seconds (explicit), on the
same file.
The culprit is that $/ set to something other than "" (or undef) slows
down the printing considerably: abnout 20%. This probably could be
improved by a lot.
--
Bart.
Re: Things to remove
?pattern? # one-time match Oi! Scott! No! I use this in one-liners, and it's _dead_ handy. Of course, if it's modularized as Dan suggests, which has no effect at language level, I wouldn't be unhappy. Mx. -- See, the stars are shining bright Everything's all right tonight -- (Martin L. Gore, Never Let Me Down Again)
Re: Things to remove
Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's not a strong enough argument. The whole point is to clean up the language. Cheers! Leon -- Leon Brocard.http://www.astray.com/ yapc::Europe - September 22-24 London - http://yapc.org/Europe/ ... Error 404: .signature generator ran out of tuits
Re: Things to remove
Leon Brocard [EMAIL PROTECTED] writes: Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's not a strong enough argument. The whole point is to clean up the language. However, it is a good argument for making sure that such functionality isn't removed from the language, even if the syntax changes. -- Piers
Re: Things to remove
On Tue, 08 Aug 2000, Leon Brocard wrote: Martyn J. Pearce sent the following bits through the ether: I use this in one-liners, and it's _dead_ handy May I suggest that Perl6 will be a different language? I've seen the "I use it, don't change it" argument a couple of times now and it's not a strong enough argument. The whole point is to clean up the language. Most of the requests for deletion seem to begin with, "This isn't used..." To which, "*I* use it." is a very valid argument. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. Just a thought to chomp on.. E Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Things to remove
On Tue, Aug 08, 2000 at 03:46:45PM +, Ed Mills wrote: As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. TMTOWTDI. chop() and chomp() should stay (IMHO). Your "println" suggestion has merit though. There's already a way to accomplish it via a command line switch (-l), but I guess what you're after is a language level method to turn automatic addition of newlines on and off. How about a new lexical pragma--newlines? use newlines; print "Hi"; # Automatically adds the newline no newlines; print "Hi"; # Does NOT automatically add the newline -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Things to remove
Thus it was written in the epistle of Jonathan Scott Duff,
Someone proposed (I think I deleted that email) to make
while (FH) { ... }
work like
while (FH) { chomp; ... }
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
Most of the fundamental ideas of science are essentially simple, and may, as
a rule, be expressed in a language comprehensible to everyone.
-- Einstein, Albert (1879-1955)
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: Things to remove
Bennett Todd wrote: There are many intents and points to this project. As _I_ see them, they include, in no particular order: - cleaning up the language definition, where practical without losing the distinctive appeal of perl to happy perl programmers; - cleaning up the implementation, to better support further growth, and possibly allow perl to better penetrate other areas (e.g. embedded applications); - cleaning up the development process, to allow people who wish to focus on specific aspects of perl development to more easily concentrate their attentions; and - adding fundamental new features to allow perl to better support new and different ways of programming, and new application domains. As long as there is a reliable perl5-to-perl6 translator, I would definitely include: - Remove relatively little-used features, as long as they can still be done (in some cases, maybe by including a 'perl5compat' module) and as long as automatic translation is Good Enough in most cases. It would be silly to say that every one-liner must remain working or that no one-liner should become longer. Does anyone have a better name than 'perl5compat' for an 'old cruft' module? Hildo
Re: Things to remove
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal was to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
something like this:
$fh = open "foo" or die;
$fh-auto_chomp = 1;# Insert some appropriate syntax
$fh-newline = "\n";# Insert some appropriate syntax
while ($fh) {
...
}
close $fh;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Things to remove
Bennett Todd [EMAIL PROTECTED] writes: The poster you are replying to said "I use this in one-liners, and it's _dead_ handy."; that conjures up the idioms like perl -nle 'print if 1.. ?^$?' [filename] which barfs out only the header; replace "if" with "unless" and it chops the head off. Why do you need one-time matching here? /^$/ should work fine. I've very rarely found cases where ?? was useful and // didn't work, and never in regular code. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Things to remove
Most of the requests for deletion seem to begin with, "This isn't used..." To which, "*I* use it." is a very valid argument. Agreed. The real problem with ?...? is that it complicates the hell out of the parser. So long as the special magic is retained for m?...?, I would suggest that raw ?...? could beneficially disappear. Damian
Re: Things to remove
Perl++ :) On Tue, 8 Aug 2000, Bryan C. Warnock wrote: On Tue, 08 Aug 2000, Bennett Todd wrote: If perl6 substantially fails to fill the important roles that perl5 fills, we should stop screwing everybody up by calling it "perl", and call it something else. Hmmm. I vote for "Edsel." -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
Today around 6:55pm, Bryan C. Warnock hammered out this masterpiece:
: chop, chomp, (champ, chimp, chump, chap, and chip, which, respectively,
: deletes all leading and trailing whitespace characters, all leading
: whitespace characters, all trailing whitespace characters, the first
: and last character, and the first character) are all efficient string
Where, oh where, did you find these? And why, oh why, haven't I found
them on CPAN already?
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: Things to remove
I like this approach, in that it places the complexity outside of the loop.
Another generalized approach might be a new $ var which turns autochomp off
and on for all fh's (are there any $'s left? :D ).
Cheers,
Ed
From: Jonathan Scott Duff [EMAIL PROTECTED]
To: Ed Mills [EMAIL PROTECTED], "Brust, Corwin" [EMAIL PROTECTED],
[EMAIL PROTECTED], 'Simply Hao' [EMAIL PROTECTED]
Subject: Re: Things to remove
Date: Tue, 8 Aug 2000 13:21:56 -0500
On Tue, Aug 08, 2000 at 01:53:21PM -0400, Ted Ashton wrote:
I'm not sure if I'm the someone you meant, but if so, the proposal was
to make
while (chomp(FH)) { ... }
work like
while (FH) { chomp; ... }
Oh. I think I'd prefer to see chomp() go away and be replaced by
something like this:
$fh = open "foo" or die;
$fh-auto_chomp = 1;# Insert some appropriate syntax
$fh-newline = "\n";# Insert some appropriate syntax
while ($fh) {
...
}
close $fh;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Things to remove
On Tue, 08 Aug 2000, Ed Mills wrote: As long as were culling, might want to consider removing chomp() and possibly chop(). The language provides other ways to accomplish those thru a simple regex, Then we should remove regexs instead. :-) and if the "println" suggestion I made was "too specific" then certainly chomp() is as well. Just a thought to chomp on.. As has been demonstrated, it is certainly trivial for you to impliment println() yourself. Maybe even contribute it to CPAN for others to use. The effect on the Perl community as a whole will be nil, as no one is using this yet. chop, chomp, (champ, chimp, chump, chap, and chip, which, respectively, deletes all leading and trailing whitespace characters, all leading whitespace characters, all trailing whitespace characters, the first and last character, and the first character) are all efficient string idioms for which a regular expression is overkill. If external modules become as efficient as we hope they are, there is no reason that *any* of the above should be CORE perl, but chop and chomp should certainly remain in the core distro. As is. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
On Tue, 08 Aug 2000, Bennett Todd wrote: If perl6 substantially fails to fill the important roles that perl5 fills, we should stop screwing everybody up by calling it "perl", and call it something else. Hmmm. I vote for "Edsel." -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
Personally, I don't think I've ever used any of these, but I really don't want to speak for everyone. Maybe an RFC "Functions and Variables to Remove in Perl 6" ? -Nate Jonathan Scott Duff wrote: Here in my pre-caffiene morning trance it occurs to me that a few of the "fringe" features of perl should be removed from the langauge. Here's a few things that I would venture to say that none of the "perl5 is my first perl" people have probably ever actually used. reset # How often do you clear variables wholesale? dump study # never been a win for me. ?pattern? # one-time match split ?pat? # implicit split to @_ What's everyone's feeling on removing these from perl6? How often are they used? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Things to remove
Jonathan Scott Duff writes: : Here in my pre-caffiene morning trance it occurs to me that a few of : the "fringe" features of perl should be removed from the langauge. : Here's a few things that I would venture to say that none of the : "perl5 is my first perl" people have probably ever actually used. : : reset # How often do you clear variables wholesale? : dump : ?pattern? # one-time match : split ?pat? # implicit split to @_ : study # never been a win for me. : : What's everyone's feeling on removing these from perl6? How often are : they used? Those are all good candidates for removal, or at least "promotion" to an external module. The only one I'd think twice about is study. For much of Perl 5's existence, it didn't get a fair shake, since it was buggy, and nobody noticed. Of course, that might be an argument for removal. :-) I'm not enamoured of the study interface, but the algorithm is definitely a win on certain classes of data. The basic problem with study is that it needs incestuous hooks into how you do string searching. So even if we moved study out into an external module, we'd still have to find some way to treat searching for constant strings as polymorphic within the regex engine. Larry
Re: Things to remove
On Sat, 05 Aug 2000, Nathan Wiger wrote: Here in my pre-caffiene morning trance it occurs to me that a few of the "fringe" features of perl should be removed from the langauge. Here's a few things that I would venture to say that none of the "perl5 is my first perl" people have probably ever actually used. reset # How often do you clear variables wholesale? dump study # never been a win for me. Perl5 is my first Perl. I use study on occasion. ?pattern? # one-time match split ?pat? # implicit split to @_ Which is currently labeled as deprecated, I believe. Most things labeled (or treated, such as pre-pod embedded docstrings) as deprecated should/could be removed. What's everyone's feeling on removing these from perl6? How often are they used? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
At 09:17 AM 8/5/00 -0700, Larry Wall wrote: I'm not enamoured of the study interface, but the algorithm is definitely a win on certain classes of data. The basic problem with study is that it needs incestuous hooks into how you do string searching. So even if we moved study out into an external module, we'd still have to find some way to treat searching for constant strings as polymorphic within the regex engine. It should be possible to write external modules that both have hooks deep into perl and are automagically loaded. We could, for a first cut, define the hooks and yank study off into one of these modules, with a "do nothing" function in there. Then, when Clever People have had a chance to go think about it, we could drop in a replacement and get the win. This, of course, presumes that defining the hooks (which will also require Clever People) can be done correctly without actually writing the code that uses it... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
