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

[Glenn Linderman]

"BSOD" => huh?  Oh, Blue Screen of Death.

Certainly if the OS doesn't support trapping an error, then the language running on it
cannot either.  But if the OS does, then the language could.  If the language could,
then the question remains whether it should, and that's a -language topic that 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: Exception handling [Was: Re: Things to remove]

[Glenn Linderman]

Tony Olekshy wrote:

> Glenn Linderman wrote:
> >
> > Just to point out that fatal is, indeed, as several people keep
> > saying, truly in the eye of the catcher.
> >
> > That said, none of the currently proposed mechanisms permit
> > "resume from fault" semantics, much less "resume from hardware
> > fault" 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]

[Tony Olekshy]

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: Exception handling [Was: Re: Things to remove]

[Glenn Linderman]

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]

[Tony Olekshy]

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 C 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]

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]

[Markus Peter]

--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]

Exception handling [Was: Re: Things to remove]

[Glenn Linderman]

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

Bart Lateur wrote:

> 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.

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne


___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html

Re: Things to remove

[Bart Lateur]

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: Things to remove

[Nathan Torkington]

Larry Wall writes:
> Now all we have to do is make the program a variable, and the two
> requirements become one.

Compile the main() program code into a subroutine called 0, and you're
off!

  &0  anyone? :-)

(that's digit 0, by analogy to $0)

Nat

Re: Things to remove

[Damian Conway]

   > 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 C
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

[Bryan C . Warnock]

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

[Dan Sugalski]

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";
> > };
> > }
> >
>
> > --tom
>Or consider this pseudo code -
> open file
> lock file
>
> dump file
>
> 

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

[Dan Sugalski]

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

[David Corbin]

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";
> };
> }
> 

> --tom
Or consider this pseudo code - 
open file
lock file

dump file



-- 
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]

Re: Things to remove

[Larry Wall]

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]

>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

[Dan Sugalski]

At 09:37 AM 8/23/00 -0700, Larry Wall wrote:
>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.

   freeze_dry &MAIN; :)

I was assuming that when you dumped an object all the anonymous code refs 
and lexically visible variables would get dumped, but package variables 
wouldn't, but that's simple enough to set with parameters, and it'd be 
useful to dump out all code that's visible to the object (all its methods 
and all the user code those methods refer to, perhaps).

A well-thought-out RFC sounds in order.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Things to remove

[Buddha Buck]

At 09:37 AM 8/23/00 -0700, Larry Wall wrote:
>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.

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);"...

Of course, someone will the write something like:

#!/usr/bin/perl6
@defaults = ('sensible', 'defaults', 'here');
exit &ME(@defaults) unless $#ARGV;
...




>Larry

Re: Things to remove

[Larry Wall]

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

[Dan Sugalski]

At 06:00 PM 8/21/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How about this then:
>:
>: In a void context, C 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

[John Porter]

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

[John Porter]

Damian Conway wrote:
> 
> Tom's opcode dumping functionality could, in principle, be added to
> Data::Dumper as it stands.
> 
> My proposal was merely that C<&Data::Dumper::Dumper> body-snatch C.

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

[Damian Conway]

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

[Damian Conway]

   > : In a void context, C 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 C<&Data::Dumper::Dumper> body-snatch C.

Damian

Re: Things to remove

[Larry Wall]

[EMAIL PROTECTED] writes:
: How about this then:
: 
: In a void context, C 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.

Larry

Re: Things to remove

[Jarkko Hietaniemi]

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

[Tom Christiansen]

>   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

[Tom Christiansen]

>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

[Nathan Torkington]

Damian Conway writes:
> If domeone is putting this RFC together, please remember to propose
> that C and C should handle opcodes as well as source:
> 
>   host-a:foo.pl:  dump SOCKET;
> 
>   host-b:bar.pl:  { local $/; eval  };
> 
> 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

[Damian Conway]

   > Instant program migration: 
   > 
   > host-a:foo.pl: print SOCKET dump;
   > 
   > host-b:bar.pl: { local $/; eval  };

If domeone is putting this RFC together, please remember to propose
that C and C should handle opcodes as well as source:

host-a:foo.pl:  dump SOCKET;

host-b:bar.pl:  { local $/; eval  };

Or:

sub suspend { open $fh, ">$_[0]" or die; dump $fh }
sub resume  { do $_[0] }

Damian

Re: Things to remove

[Jarkko Hietaniemi]

> In a void context, C dumps the program's current opcode representation
> to its filehandle argument (or STDOUT, by default).
> 
> In a scalar or list context, C dumps nothing, but rather returns the
> I of its arguments (or of the current state of the entire
> program, by default).

Instant program migration: 

host-a:foo.pl:  print SOCKET dump;

host-b:bar.pl:  { local $/; eval  };

-- 
$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

[Damian Conway]

   > > > 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 C. 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, C dumps the program's current opcode representation
to its filehandle argument (or STDOUT, by default).

In a scalar or list context, C dumps nothing, but rather returns the
I 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

[Garrett Goebel]

> 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 C. 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

[Damian Conway]

   > 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 C. But I think I like this idea even more.

Damian

Re: Things to remove

[Bart Lateur]

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

[Larry Wall]

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 () {
:   $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

[Tom Christiansen]

>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 () {
$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]

>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

[Bart Lateur]

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

[Bart Lateur]

On Tue, 8 Aug 2000 11:25:56 -0500, Jonathan Scott Duff wrote:

>Someone proposed (I think I deleted that email) to make 
>
>   while () { ...  }
>
>work like 
>
>   while () { 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

[Larry Wall]

[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

[Nathan Torkington]

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

[Steve Simmons]

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

[Bryan C . Warnock]

On Tue, 08 Aug 2000, Casey R. Tweten wrote:
> 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?

I wrote them.  (One of my first exercises in XS and Perl internals, as
a matter of fact.) They're quite trivial to produce, not taking
variations of what constitutes whitespace into account.

Because no one has submitted them, I guess.  I don't have a PAUSE
account.  I keep meaning to request one, but the justification
requirement keeps getting in my way.  :-(

(Not that that should change.  CPAN's got enough trouble as it is.)

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: Things to remove

[Ed Mills]

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()) { ... }
> >
> > work like
> >
> > while () { 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

[Casey R. Tweten]

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 

Re: Things to remove

[Casey R. Tweten]

Today around 6:34pm, Mike Pastore hammered out this masterpiece:

: Perl++

PERL

[Casey ducks and runs for cover ;]


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

Re: Things to remove

[Mike Pastore]

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

[Bryan C . Warnock]

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

[Bryan C . Warnock]

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

[Damian Conway]

   > 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

[Russ Allbery]

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

Re: Things to remove

[Jonathan Scott Duff]

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()) { ... }
> 
> work like
> 
> while () { 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

[Hildo Biersma]

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

[Bennett Todd]

2000-08-08-04:42:00 Leon Brocard:
> 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?

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.

The project name "perl6" carries a presumption in most folks' mind
that this language is intended to _replace_ perl5; that after it
goes live with a stable production release, there probably won't be
much further active development of perl5, and after a few more years
at most will die off. If we intend to abandon that goal, then let's
also abandon the name perl6. I'm sure there are plenty of other
semiprecious gemstones left that haven't been claimed by languages.
Or we could use a snake, or a comedy troupe.

> 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.

Alone, it's not. That's why it should be accompanied by a
description of _how_ the arguer uses the feature, with the intent of
indicating how valuable it is. That lets the readers make their own
judgement about whether the feature merits removal.

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.

And don't forget that the poster, who you were responding to,
finished up by saying:

> > Of course, if it's modularized as Dan suggests, which has no
> > effect at language level, I wouldn't be unhappy.

I.e. while it's useful, the use doesn't carry performance demands
sufficient to make a demand that it remain in the core; the poster
would be content if it were factored out into a loadable extension
module.

> The whole point is to clean up the language.

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.

-Bennett

 PGP signature

Re: Things to remove

[Ted Ashton]

Thus it was written in the epistle of Jonathan Scott Duff,
> 
> Someone proposed (I think I deleted that email) to make 
> 
>   while () { ...  }
> 
> work like 
> 
>   while () { chomp; ... }

I'm not sure if I'm the someone you meant, but if so, the proposal was to make

while (chomp()) { ... }

work like

while () { 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

[Riad Wahby]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] 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.

Not really.  I've provided a definition of println that is simple and
fast as a subroutine.  I challenge you to do the same (remember,
fast--no regexps, sorry) for chomp and chop given neither.

And we're not culling--we're just preventing bloat.  println was never
there, so there's nothing to cull.

Riad Wahby
[EMAIL PROTECTED]
[EMAIL PROTECTED]

5105
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5kC5GiHor6RkxxqYRAkp1AJ9f774bPQD9rfMFpLO1CUn8v0CmsQCfZD2n
VjvNpVN9aD60QtLLIVZoY98=
=V5H4
-END PGP SIGNATURE-

Re: Things to remove

[Jonathan Scott Duff]

On Tue, Aug 08, 2000 at 11:12:40AM -0500, Brust, Corwin wrote:
> From: Simply Hao [mailto:[EMAIL PROTECTED]]
> 
> >> might want to consider removing chomp() and possibly chop().
> >
> >They're faster than regexes, right?
> 
> 
> Dunno about faster but  so sweet.
> 
> I like 
> 
>   while (<>) { print chomp } 
> 
> better then
> 
>   while (<>{ 
> s/$/$//;
> print
>   }
> and it *seems* like it would be faster

Someone proposed (I think I deleted that email) to make 

while () { ...  }

work like 

while () { chomp; ... }

If this were to happen, then I'd fully support removing chomp() from
the language as long as there was a way to turn that behavior on and
off, of course. (use/no chomping anyone?)  We're going to have to
revisit chomp() anyway if we make $/ per-filehandle because chomp()
acts on strings, not filehandles.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

RE: Things to remove

[Brust, Corwin]

From: Simply Hao [mailto:[EMAIL PROTECTED]]

>> might want to consider removing chomp() and possibly chop().
>
>They're faster than regexes, right?


Dunno about faster but  so sweet.

I like 

while (<>) { print chomp } 

better then

while (<>{ 
  s/$/$//;
  print
}
and it *seems* like it would be faster

-Corwin

Re: Things to remove

[Jonathan Scott Duff]

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

[Simply Hao]

> might want to consider removing chomp() and possibly chop().

They're faster than regexes, right?

-Hao

Re: Things to remove

[Ed Mills]

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

[Ted Ashton]

Thus it was written in the epistle of Leon Brocard,
> 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? 

Actually, I think the point is that Perl6 won't be a different language.  
"Improved", yes, "New", no.  There will be some syntax changes and some things
will work differently, but if something is "_dead_ handy" it needs to be at
least that handy when we get done :-).

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
The human mind has first to construct forms, independently, before we can
find them in things.
-- Einstein, Albert (1879-1955)
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: Things to remove

[Bryan C . Warnock]

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

[Piers Cawley]

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

[Leon Brocard]

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

[Martyn J. Pearce]

>   ?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

[Dan Sugalski]

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

Re: Things to remove

[Bryan C . Warnock]

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

[Larry Wall]

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

[Nathan Wiger]

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]