RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy [EMAIL PROTECTED]
Date: 08 Aug 2000
Last Modified: 23 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 ABSTRACT
"The Encyclopedia of Software Engineering" [ESE-1994] says (p.847):
Inevitably, no matter how carefully a programmer behaves when
writing a program and no matter how thoroughly its verification
is carried out, errors remain in the program and program
execution may result in a failure. [...] The programming
language may provide a framework for detecting and then handling
faults, so that the program either fails gracefully or continues
to work after some remedial action has been taken to recover
from the error. Such a linguistic framework is usually called
exception handling.
This RFC describes a collection of changes and additions to Perl,
which together support a built-in base class for Exception objects,
and exception/error handling code like this:
exception 'Alarm';
try {
throw Alarm "a message", tag = "ABC.1234", ... ;
}
catch Alarm = { ... }
catch Alarm, Error = { ... }
catch $@ =~ /divide by 0/ = { ... }
catch { ... }
finally { ... }
Any exceptions that are raised within an enclosing try, catch, or
finally block, where the enclosing block can be located anywhere up
the subroutine call stack, are trapped and processed according to
the semantics described in this RFC.
The new built-in Exception base class is designed to be used by Perl
for raising exceptions for failed operators or functions, but this
RFC can be used with the Exception base class whether or not that
happens.
Readers who are not familiar with the technique of using exception
handling to handle errors should refer to the LCONVERSION section
of this document first.
It is not the intent of this RFC to interfere with traditional Perl
scripts; the intent is only to facilitate the availability of a more
controllable, pragmatic, and yet robust mechanism when such is found
to be appropriate.
Nothing in this RFC impacts the tradition of simple Perl scripts.
Ceval {die "Can't foo."}; print $@; continues to work as before.
There is no need to use try, throw, catch, or finally at all, if
one doesn't want to.
This RFC does not require core Perl functions to use exceptions
for signalling errors.
=head1 DEFINITIONS
raise
An exception is raised to begin call-stack unwinding according
to the semantics described herein. This provides for controlled
non-local flow-control. This is what Cdie does.
propagate
The passing of an exception up the call stack for further
processing is called propagation. Raising an exception
starts propagation. Propagation stops when the exception
is trapped.
unwinding
The overall process of handling the propagation of an exception,
from the point it is raised until the point it is trapped, is
called unwinding.
trap
The termination of unwinding for the purpose of attempting
further processing using local flow-control semantics, is
called trapping. This is what Ceval does.
cleanly caught
This means the trapper of an exception did not itself raise an
exception.
exception
An exception is a collection of informaton about a particular
non-local goto, captured at raise-time, for use by trap-time
handling based on said informaton. This is what C$@ is.
error
A fuzzy concept, an error is essentially an exception with a
negative connotation. A traditional definition might be, "an
exception raised to signal an assertion failure that typically
indicates the inability of an algorithm to complete the request
it has been given". Ultimately, whether or not an exception
is considered to be an error depends on the trapper, not the
raiser.
=head1 DESCRIPTION
The most common forms of structured exception handling are straight-
forward. Here they are:
try { ... } catch { ... }
Invoke the catch block only if the try block raises an
exception (aka dies), otherwise, there is nothing to catch.
Continue unwinding (propagate $@) only if the catch block
was invoked and it raises an exception too.
Otherwise, execute the next statement according to local
flow-control, because either no exception has been raised by
either block, or one was raised in try but it was cleanly
caught.
try { ... } finally { ... }
Invoke the finally block whether or not the try block raises
an exception.
Continue unwinding (propagate $@) if either the try block or
the finally block raised an exception.
Otherwise, execute the next statement according to local
flow control, because no exception has
Re: RFC 63 (v4) Exception handling syntax
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote: PRL Exceptions are objects belonging to some CException class. Cthrowing PRL an exception creates the object; therefore, CEXCEPTION above is just a PRL class name (possibly including some C::). PRL PRL The Cexception function is just syntactic sugar for creating a new PRL exception class;it merely amounts to C@EXCEPTION::ISA = 'Exception'. Often people want to create hierarchies of exception classes. In proposed implementation 'exeption' keyword doesn't allow to create exception classes subclassed from other exception classes. IMHO in such implementation this keyword will not be very usefull. From the beginning of the posting you're quoting: This RFC has been merged into RFC 88. The text of the last version prior to the merge is left below for archival purposes only. Anyone interested in browsing this for historical reasons probably has way too much time on their hands :-) -- Peter Scott Pacific Systems Design Technologies
Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
Woohoo!
catch Alarm = { ... }
catch Alarm, Error = { ... }
catch $@ =~ /divide by 0/ = { ... }
The = here seems like useless syntax to me.
try { ... }
catch MatchThis = { ... }
catch MatchThat = { ... }
catch { ... } # everything else
finally { ... }
Let me tell you some semantics and syntax that I've thought of ...
they're remarkably similar to yours ;-)
try { ... } # For every one of these, we have
catch BAREWORD { ... } # zero or more catch clauses
catch METHOD{ ... }
catch LIST { ... }
catch EXPR { ... }
catch { ... }
finally { ... } # and exactly zero or one of these
If the target of a catch is a BAREWORD or a string, it is taken to be
a class name and act as if $@-isa(BAREWORD) or $@-isa(STRING) were
invoked. If the isa() is true, the block executes.
If catch is given a METHOD (subroutine), it's evaluated as if
$@-METHOD were executed (with whatever arguments). If no such method
exists in the exception hierarchy for the thrown exception, it's taken
to be a normal subroutine and just executed. If the METHOD or
subroutine evaluate to true, the block is executed. (To force Perl to
treat it as a subroutine in the current package, explicitly qualify
it. I expect this usage to be rare, but I could be wrong.)
If catch has a LIST, each element of the list is evaluated as above
and if *any* of them return true, the catch block executes.
Otherwise, any arbitrary expression can be evaluated for truthness.
And Ccatch { ... }, of course, catches any exception. And Cfinally
{ ... } is always executed no matter what.
Upon completion of a catch block, the exception is considered handled.
If the catch block contains Cthrow; the current exception is kept on
the stack for subsequent catch blocks to deal with. Quick example:
try { 23 / 0 } # throws Math::DivideByZero
catch Math::DivideByZero { ... throw; } # not handled
catch Math::DivideByZero { ... }# handled.
finally { ... } # end processing.
A Cthrow inside of one of the catch blocks simply pushes the
exception on the stack and subsequent catch blocks get a chance to
handle it. If none of the catch clauses handle the exception, it's
propigated to the next enclosing exception handler after the finally
block is executed.
If multiple statements are required to compute the value of the
EXPR, use this form: catch do { a; b } = { ... }
Or how about just this:
catch { a; b } { ... }
Yes, I realize some hoops may have to be jumped through to
distinguish these:
catch { ... } # all exceptions
{ ... } # random code, Oops!
catch { ... } { ... } # catch only if the first block is true
But that's what computers are for!
No, now that I think about it, requiring the Cdo is best:
catch do { ... } { ... }
But that = still seems superfluous to me.
The "try" is not for Perl's sake. It's for the developer's
sake. It says, watch out, some sort of non-local flow control
is going on here. It signals intent to deal with action at a
distance (unwinding semantics). It satisfies the first rule
listed under LMOTIVATION.
Hmm ... I wonder if there's a way we can tell builtins (like open)
that they are to throw exceptions if they appear in try blocks?
Syntax
The comma or = in the catch clause is required so the
expression can be parsed from the block, in the fashion
of Perl 5's Cmap expression, list;
You mean like this?
@doubles = map { $_*2 } @numbers;
I don't see a comma or = in there at all ;-)
Lexical Scope
The authors would prefer that try, catch, and finally blocks
share the same lexical scope.
A few of us random commentators agree with this as well.
my $cents = 2;
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote:
But I initially wanted to do without the = ... unfortunately that would
require another keyword to handle the EXPR case and it didn't seem
worth it.
Not necessarily.
catch { EXPR } { ... } # probably not going to work though
catch (EXPR) { ... }# this will work
catch do { EXPR } { ... } # this will work
Um, granted, but if you're going to need additional syntax around your EXPR
to disambiguate it then = seems as good as any and it has that neat "this
thing causes this thing" interpretation.
Okay, I'm just registering my opinion that I don't like it. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the flag)
Ala, taint? Except the variable is tainted with death?
Hmm, this would make two types of undef. Actually, if a callee could
death-taint a variable then the return death_tainted(42) would make
the caller check his values on first use.
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the flag)
Ala, taint? Except the variable is tainted with death?
Yes, sort of. "Touch me and I'll bring you down."
Hmm, this would make two types of undef. Actually, if a callee could
(Not really undef, boolean, see Tom's reply). But in either case not
a problem since the user should have no explicit means of telling the
kinds part nor certainly ways of changing the kind.
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
Tough.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
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: RFC 119v2: Object neutral error handling via exceptions
Tony Olekshy wrote:
Yes, well, at this point I must re-iterate that (in light of reasons
for the existence of a try keyword that I have explained in other
messages), what you've written is the same as:
try { ... } finally { do_something(); }
Yes, they are equivalent.
And note that
{
always { do_last(); };
always { do_next_to_last(); };
always { do_third_from_last(); };
...
}
is equivalent to
try { ... }
finally { do_third_from_last (); }
finally { do_next_to_last (); }
finally { do_last (); }
And is also be equivalent to:
{ ... }
always { do_last(); }
always { do_next_to_last(); }
always { do_third_from_last(); }
So, I think, try/throw/catch/finally/exception are orthogonal (now
that we all agree what that word means) to "always", that "always"
should stand on it's own, that "always" is a good idea (I mean, it
has been discussed in p5p in the past), and that it should have its
own RFC.
So can we agree finally and always are basically the same thing? I only
used the word "always" in RFC 119 to avoid confusion until it became
apparent they were the same. So really, you could remove "finally" from
RFC 88--it should be a different RFC, by your standards.
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: Why $@ should be structured data.
Tony Olekshy wrote:
There you have it. That's why RFC 88 uses structured data for $@.
That's a good argument, one that I have no quarrel with. As an
enhancement to eval/die, this would make it more flexible for checking
conditions. And with appropriate stringification, it is upward
compatible with the current uses of $@ by eval/die.
Transliterating $@ to whatever would be used equivalently for an
exception mechanism, I still agree that structured data is good.
Now, here's an alternative that may keep everyone happy. In
addition to whatever RFC 88 does now, change this rule about how
die behaves:
If passed a single argument that isa "Exception", raise it as
the new exception and die in the fashion that Perl 5 does.
Otherwise, the arguments are stringified and joined with C''
(as in Perl 5), the resulting string is wrapped up in a new
Exception object (setting the message instance variable to said
string), and the new Exception object is raised.
to read like this:
If passed a single argument that isa "Exception", raise it as
the new exception and die in the fashion that Perl 5 does.
Otherwise, the arguments are stringified and joined with C''
(as in Perl 5), the resulting string is wrapped up in a new
Exception object (setting the message instance variable to said
string), the original unstringified arguments are saved in a
list ref in the object's Cargs instance variable, and the new
Exception object is raised.
then you can say Cdie qw(A B C), and the following tests both work:
catch $@-args-[1] eq "B" = { ... }
catch $@ =~ /B/ = { ... }
Yours, c, Tony Olekshy
We're getting closer and closer. Now we just need a magic array such
that before the first catch clause is executed, it gets assigned the
contents of @{$@-args}. I guess (per your other postings), that could
be achieved via RFC 88 functionality by:
try on_catch_enter = sub { @! = @{$@-args}; return true; },
{ ...
}
catch $![0] == 53 = { ... };
On the other hand, that would conflict with your use of on_catch_enter
for other purposes, but I use it to demonstrate the functionality I'd
like to see: that catch can directly access the list of arguments passed
to throw, whatever they are. I'm not sure I fully understand the way the
on_catch_enter hook works or is set, and I don't want to have to actually
do this to achieve the goal.
--
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: Why except and always should be a seperate RFC.
Tony Olekshy wrote:
Other than for the except and always clauses, RFC 199 is very
similar to RFC 88. I like the idea behind except and always,
but I think the proposed implementation could be dramatically
simplified.
The first thing to realize is that just because 119 doesn't say
"try" the doesn't mean it isn't there, it's just implied.
This is true. RFC 119 explicitly suggests that _all_ code be in an
implicit try block, as it includes definitions for implicit catch
phrases to be included at the end of the main scope. This causes
_absolutely no effect_ on any program that doesn't use the RFC 119 throw
keyword, and there are no programs today that do so. The first effects
of RFC 119 are when a programmer chooses to use one of its features.
And no other features are affected by that choice. It is orthogonal to
all other features of Perl.
To my
understanding, in order to be able to try, catch, or finally at all,
one must pre-arrange to have changed the exit-sequence code for a
block that has try, catch, or finally semantics, whether implicit
or not, because one has to do the stack unwinding thingy for such
blocks.
Well, that's true if you assume that the normal exit sequence for a
block does not support stack unwinding. And that assumption is true for
languages that don't have exception handling built in, but rather tack
it on. And that same assumption is true for some languages that build
in exception handling, but attempt to limit the scope of when it
applies. Perl5 is such a language. Perl6-including-RFC-119 might
support exception handling as a normal part of the exit sequence for a
block.
That's why some references mention that it may be difficult
to do a local goto across a non-local unwinding boundry. On the
other hand, Perl is not so tied to hardware, so this may not be
difficult to arrange at all.
Especially in perl6.
Whether or not local gotos out of unwind flow-control blocks can
be implemented does not impact the usefulness of the concepts of
except and always. If those gotos can be done they will be,
otherwise they won't; it will have the same impact on 88 and 119.
Correct.
So, lets say we had a syntax like this:
{
my $foo = $bar always expr;
my $foo = $bar always block;
my $foo = $bar always code_ref;
...
}
The given expr, block, or code_ref would be evaluated just
before its associated lexical variable goes out of lexical scope,
including due to unwinding.
I don't consider the lexical variables to be particularly tied to the
always block. Because the first statement in each of these examples
defines a lexical variables, in some sense it is tied, but the always
block is more particularly tied to the statement; the statement in these
examples happens to define a new lexical variable. So there is nothing
wrong with your statement, but it draws a closer relationship between
the defined variables and the always clause than would always exist.
If some action is to be taken on end-of-scope, but only if an
exception is being caught (like RFC 119s "except") it can simply
be coded like this:
my $foo = $bar always { $@ and catch_it($foo); };
Presuming that exceptions set $@, and that the truth of $@ reflects the
existance of an exception (both of which are true for RFC 88, but
neither of which are currently required to be true for RFC 119), then
you are correct, it could be coded that way.
"except { ... }" is syntactic sugar for "always { if (we are unwinding
the stack due to an exception) { ... }}"
This is nice syntactic sugar, I like it. It hides the logic in
above, which hopefully is simple, but of which novices need not be
aware.
because in an always (like in a finally in RFC 88), defined $@
indicates whether an exception is being handled, or normal local
processing is taking place.
This is assuming facts not in RFC 119, regarding its use of $@.
This RFC would need some notes about where exactly "always" hooks
into the rules described in a generic mechanism like RFC 88, and
perhaps an RFC-88 style mechanism hook for invoking a callback
whenever an "always" is entered, like this:
try on_always_enter = sub { ... }, { ... }
Note that since RFC 88 uses a "try" keyword to establish the
context in which a "finally" keyword is expected, and since
the my $foo examples above don't have such context, "always"
can probably be renamed "finally" without the parser getting
confused about RFC 88's finally.
And that would pretty much be my version of the "always" RFC.
Yours, c, Tony Olekshy
Generally, assuming RFC 88, that'd be a pretty reasonable "always" RFC.
As noted above, "except" is, in my opinion, helpful syntactic sugar.
As noted in other posts, you can eliminate your finally clause from RFC
88 altogether, because it is one and the same with "always" (especially
an "always" that is renamed "finally"), and should, by your standards,
be a separate RFC.
So far, neither of us has made
Re: Why fatal errors aren't special.
At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote: By building up a non-fatal error handling technique on top the existing fatal error handling technique, you are forcing code that assumes it will die to behave differently, when you wrap a try block around it. Now it will only "maybe" die. There are no existing fatal exceptions. You can call die as much as you want, but if your caller has wrapped you in an eval block, tough. RFC 88 does not change this at all. -- Peter Scott Pacific Systems Design Technologies
Re: Structured exception handling should be a core module.
Peter Scott wrote: At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote: In fact, not only would I be pleased and honoured to author the Perl 6 core Try.pm module, I'm already working on a Perl 5 standard reference implementation. Peter, I think we should make this approach more clear in RFC 88. I'm not convinced that this can totally be implemented in a module. Particularly if RFC 151 passes :-) I've read 151 a few times, and I don't understand how it can impact the implementation of RFC 88 as a module. Please explain. Yours, c, Tony Olekshy
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
JH Tough.
Not a nice attitude. The failure is not close to the cause. Neither in
time or space.
If it were closer to the open, at least an intellegent message might
be displayed. Your way, nothing but.
*ARRGGHHH*, tainted data, in Foo.pl at line 37 chunk 12
(Why does that remind me of rogue?)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: On the case for exception-based error handling.
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote:
actually wrapping a bunch of code inside a try block
affects how that code reacts to die, thus affecting the
behavior of the program that previously used die to mean
terminate the program.
Hang on, this can't be true. To quote from RFC 88:
try { may_throw_1 }
catch may_throw_2 = { may_throw_3 }
finally { may_throw_4 }
is exactly the same as (assuming traditional Perl semantics):
eval { may_throw_1 };
my $exception = $@;
if ($exception) {
my $test = eval { may_throw_2 };
$@ and $exception = $@;
if ( ! $@ and $test ) {
eval { may_throw_3 };
$exception = $@;
}
}
eval { may_throw_4 };
($exception ||= $@) and die $exception;
How can this affect how code reacts to die? It reacts the same
as with eval, whether wrapped in a try or not. Say I had:
do_something();
now I wrap it in a try:
try { do_something(); }
this is equivalent to:
eval { do_something(); };
my $exception = $@;
$exception and die $exception;
Which is *exactly* the same as bare do_something(); as per Perl 5.
OK, this example clearly demonstrates something.
99% of the catch clauses in the world should be conditional,
handling only those specific exceptions that it knows about, and
knows it can handle. The "catch-all" (unconditional catch of
anything), is error prone; [...] a "catch-all" might bite off
_lots_ more than it should chew. Maybe "catch-all"s that do
something and then re-throw would be relatively safe.
Yes!
Only when one knows an awful lot about what's going on in the body
of a try is a catch-all that does much more than set a state
variable and re-throw possibly safe, because by definition once an
exception has raised there are a bunch of things one shouldn't make
too many assumptions about.
Here is one possibly safe example:
try { $y = ( $a * $x * $x + $b * $x + $c ) / $d; }
catch { $y = undef; }
but this would be even safer:
try { $y = ( $a * $x * $x + $b * $x + $c ) / $d; }
catch Exception::CORE::Math = { $y = undef; }
The only case where catch really should be unconditional (and not
just re-throw) is when top-level (some sort of main.pl) code wraps
the whole shebang in a try with this type of explicit purpose:
try { the_whole_shebang() }
catch { pass_to_client($@-show(label = 1, trace = 1)) }
Where pass_to_client may be print + exit;
Yours, c, Tony Olekshy
RE: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like with or express
-Original Message-
From: Bart Lateur [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 23, 2000 7:00 PM
To: [EMAIL PROTECTED]
Subject: Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like
"with" or "express"
On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote:
Normally what you'd say is:
with (%record) {
}
(look at me, using Larry's new ... operator :-)
No you didn't. You typed four dots.
--
Bart.
Hmmm
... . ...;
or maybe:
while (... .. ...) {
q(can't touch this!)
}
-Corwin
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Thu, 24 Aug 2000, Hildo Biersma wrote: Don't impose your religion on others. If people want 'this' instead of 'self', that should be just fine. It should be pretty easy to define the appropriate $ME-reader like this: use ObjectStyle 'self'; or use ObjectStyle 'Java'; for the appropriate, per-module scoped, definitions for: - self vs this - super vs SUPER vs base vs parent - DESTROY vs finalize vs destructor - default of 'private', 'protected' or 'public' and any others we can come up with... I'm all for TMTOWTDOI but I really object to this idea. I have enough to deal with when reading other's modules without having to look for DESTROY *or* destroy *or* finalize *or* I_am_dying *or* whatever. Perl needs to walk a line between being flexible and remaining a language where I can download something from CPAN and have some chance of understanding it. Maybe the following would be ok: use self; # otherwise object is in @_ That I could live with. 4 different sets of object names and special sub names would kill me. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
sub do_stuff {
my $self = self;
$self-{STATE}-{something} = @_;
}
sub error {
carp @_ if self-config('VerboseErrors');
}
I've never really seen anything like this before in other languages (Is that
good or bad?). The closest is Java's odd use of the super function as the
first line of a constructor.
The first problem I see with this is in [my understanding of] how perl
handles objects currently.
func class csv;
is the same as
class-func( csv )
Which internally becomes a lookup for the proper func based on @ISA, but
ultimatly class gets unshifted onto the stack of parameters.
The only way I can see an easy way of hiding the passage of $self is by
offsetting @_ by one, making $_[ -1 ] = $self. Which is obviously
unaddressible. Self would simply make the internal c array-lookup to
[ -1 ]. Either this sort of space would always have to be available, or the
function itself would have to be flagged for it... As in:
sub do_stuff: method {
my $this = self; # I'm old fashioned, leave me alone
} # end do_stuff
All accesses to methods would then require the method function-attribute.
Otherwise self could just be an alias for shift. In this way, you maintain
compatibility (except for those poor souls that currently use method,
locked)
-Michael
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote:
It's a pain if you want to support both function-oriented and
object-oriented calling forms, as CGI.pm does. For example, you can use
both of these:
print header;
print $r-header;
with CGI.pm. Now you need a self_of_default special method, since
sometimes $_[0] has a class ref and sometimes it has the first method
argument.
Don' forget to mention that if the sub can also be used as a class
method, the is NO WAY to distinguish between
CGI-header
and
header("CGI")
Hence, with some values for the functional argument, the detection
mechanism is unreliable.
Either $ME or self() (which, BTW, is more related to caller() than to
ref()) is 100% reliable.
--
Bart.
Re: RFC 144 (v1) Behavior of empty regex should be simple
I propose that this 'last successful match' behavior be discarded entirely, and that an empty pattern always match the empty string. I don't see a consideration for simply s/successful// above, which has also been talked about. Thas would also match expected usage based upon existing editors. --tom
Re: RFC 150 (v1) Extend regex syntax to provide for return of a hash of matched subpatterns
This is useful in that it would stop being number dependent. For example, you can't now safely say /$var (foo) \1/ and guarantee for arbitrary contents of $var that your you have the right number backref anymore. If I recall correctly, the Python folks addressed this. One might check that. --tom
Re: RFC 150 (v1) Extend regex syntax to provide for return of ahash of matched subpatterns
At 11:23 AM -0600 on 8/24/00, Tom Christiansen wrote: This is useful in that it would stop being number dependent. For example, you can't now safely say /$var (foo) \1/ and guarantee for arbitrary contents of $var that your you have the right number backref anymore. Good point. Thanks. If I recall correctly, the Python folks addressed this. One might check that. I'll do that, though for irrational, chauvinistic reasons I'm reluctant to imitate Python too closely.
Re: RFC 153 (v1) New pragma 'autoloader' to load modules on-demand
A main goal for Perl 6 is to make it faster, more compact, and lighter weight. This means moving lots of former core functions into modules. Andy D once posted something showing empirical evidence that this hypothesis is in fact *FALSE*. And I was taught that given a false hypothesis, nothing can be said of the conclusion. So I won't. :-)_ --tom
Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default
Chaim Frenkel wrote:
Why this limitation?
If the lvalue is a fundemental type (whatever that is) everything works
as if the lvalue were actually in place
sub foo { return $a }
foo =~ s///;# same as $a =~ s///;
This is not the type of lvalue sub that this RFC proposes be enabled by
default. This is a "true" or "complex" lvalue sub.
My RFC proposes that this sub:
sub assign ($var, $val) {
my $oldval = self-{STATE}-{$var};
self-{STATE}-{$var} = $val if $val;
return $oldval;
}
Can be called as any of these forms by default:
$old = assign($var, $val);
$old = assign($var) = $val;
$old = assign = $var, $val;
Make sense? This RFC doesn't address true lvalue subs, rather that
rvalue subs should be able to be used in an lvalue assignment context by
default. It is a limited but valuable syntactical tool.
-Nate
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
[OT] How to pronounce 'www' (was Re: ... as a term)
On Wed, Aug 23, 2000 at 11:43:04PM -0400, Uri Guttman wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) [snip of other possibilities] the variation i learned somewhere was "wuh wuh wuh". it's about the shortest vowel sound you can use. This is getting way off topic, and I apologize in advance. I use "dub dub dub", which I picked up at Intel. I find it much easier to pronounce quickly than anything that uses an approximant. -dlc
Re: [OT] How to pronounce 'www' (was Re: ... as a term)
On Wed, 23 Aug 2000 20:58:02 -0700, Daniel Chetlin wrote: I use "dub dub dub", which I picked up at Intel. I find it much easier to pronounce quickly than anything that uses an approximant. http://x74.deja.com/[ST_rn=ps]/getdoc.xp?AN=603967285 I do like "wibbly". Or "wibble". It has a nice mental representation of what "www" looks like: a few waves. And now, back to your regular scheduled program. -- Bart.
Re: RFC 133 (v1) Alternate Syntax for variable names
Michael Maraist wrote:
my var; # declaring a scalar
my array[]; # declaring an array
my hash{}; # declaring a hash
Though the declarations seem fine, I assume that you propose this to be
optional at usage time, since variable interpolations such as
"xxx${var1}xxx${var2}xxx" really need the prefix. One of the great
strengths of perl is in fast and simple string manipulations. Currently,
it's unabiguous as to how here-document simpler strings get interpolated.
Compare that to Java's:
"str" + var + "str"
or python's:
"xxx%sxxx" % var
-Michael
At interpolation time, I think you're explictly specifying the context
the variable is in, so the answer is "yes",
though you may also be trigger in the 'quote operator' to recognize
variable interpolation should be performed.
I think all of the following might work.
$x = "xx${var}yy";
$x = "xx$var\yy";
$x = "xx".var."yy";
and for the more complex variables,
$x = "xx".@array."yy";
$x = "xx".array[]."yy";
$x = "xx".@array[]."yy"; # not so sure about this one.
# I'm not sure at all about these - I tend to avoid interpolation of
arrays and hashes for "safety"
$x = "xx@{array}yy"
$x = "xx{array[]}yy"
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
RFC 143 (v1) Case ignoring eq and cmp operators
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. =head1 DESCRIPTION =head2 Problems with current ways to do it Perl currently knows basically two methods for checking of equality of strings case-insensitively: uc($a) eq uc($b) $a =~ /^$b$/i and for comparing them one: uc($a) cmp uc($b) The probably worst about these statements is that they look ugly. Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? The regexp mechanism has a case-insensitivity option (there's probably no proper way to simulate it there I admit). With this in mind most beginners will conclude the same is true for eq and cmp - after all Perl is strong in text processing so how could such a feature miss? Beginner code usually ends up using the case-insensitive regexps then instead of the easier to read uppercase/equals combination. =head2 Proposal We apply something similar to the regexp modifiers to Ceq and Ccmp as well, after a slash. The above examples would then be $a eq/i $b $a cmp/i $b This still leaves some room for future additions to eq and cmp if desired (stupid example: like ignoring all white space in the comparison or whatever comes up) =head1 IMPLEMENTATION Probably has to be added to perl internals... I wonder what will happen with overloads though - is eq/i a new operator to overload or is the case-insensitivity somehow magically done by the Perl interpreter even though eq was overloaded? This probably could lead to problems... =head1 REFERENCES perlop manpage for eq and cmp String.equalsIgnoreCase() method in Java
RFC 147 (v1) Split Scalars and Objects/References into Two Types
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Split Scalars and Objects/References into Two Types
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 23 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 147
Status: Developing
=head1 ABSTRACT
Many RFC's have been proposed dealing with Perl's current prefixing
system. Many have criticized it, even suggesting to drop prefixes
altogether, but the vast majority of these criticisms center around one
thing: Not being able to tell the difference between "true" scalars and
references/objects.
The answer to this has frequently been that the $scalar type defines not
a quality, but a quantity: one. While true in one sense, Perl does have
both @arrays and %hashes, notations which do the opposite: define a
quality. While they are both composed of multiple things, those things
are fundamentally different, and hence the need for two notations.
References and true scalars ("scalars" henceforth) are also
fundamentally different things. Therefore, this RFC proposes that they
be split into two separate types in Perl 6: $scalars and *references.
Please take the time to read this. It is a thorough document that
explores both the pros AND cons of this approach.
=head1 DESCRIPTION
Please note that the * is used as the reference prefix in this
document. Nonetheless, this proposal has NOTHING to do with typeglobs,
and using the * prefix would require typeglobs to disappear. The prefix
is debatable, let's focus on the idea.
=head2 The Problem
Everyone on this list should be familiar with the problem. You can't
tell scalars and references apart by looking at them. They are
completely ambiguous. Consider:
$stuff{key} # hash value
$stuff[0]# array value
$stuff # scalar or reference?
%stuff # hash
@stuff # array
$stuff # scalar or reference?
You get the idea. In simple examples, this ambiguity goes away because
of the way you address them:
$stuff # scalar or reference?
$stuff-{key}# hash reference
$stuff-[0] # array reference
$stuff-func # object reference
Once we use them, we recognize that the last three are references.
However, there are many situations when we can't disambiguate them:
$stuff = Class-method# scalar or reference?
read_data($stuff) # scalar or reference?
$$stuff # scalar or reference?
Good variable names help, but the fact remains that these are
fundamentally different types. For example, you know what will happen
when you do this:
print @stuff # the contents of @stuff
while(($k,$v) = each %h)) # each key/value of hash %h
But what about these examples?
$z = $x + $y # numeric addition?
$stuff ||= "Bob" # is this correct?
print ref $stuff # sure about that?
Anyone who has worked on a large project in Perl will relate to the fact
that even this code block is difficult to read unless you know exactly
what the functions are supposed to return:
$c = Class-new; # ok (maybe) so far...
($u, $g) = $c-get_user;
($d, $f, $j, $m) = $c-read_data;
# ... lots of code passes ...
print "Thanks $u for your ", $g-purchase;
$member = $d || $CLASS_DEFAULT; # scalars or
while (($k,$v) = each %$f) {
print "Now updating info for $k...\n";
push @$j, @{ $v-{'personal'} };
$name = $member-name($$v-{name}-{first}) || "unknown";
}
print "Your confirmation number is $m\n";
Here, we've lost the advantage of prefixes. While there are lots of $'s
in the code, they don't tell us anything useful other than "there's a
single something here". [1]
However, note that the @ and % still do, because they indicate quality
in addition to quantity.
=head2 The Proposed Solution
This RFC proposes that references and scalars be split into two distinct
types. This is not a novel approach. It is also not a simple one. There
are many issues to address.
However, the dividing line is clear:
Type Definition
- --
$scalar Holds a single simple value, such
as a string or number
*referenceHolds a single complex value, such
as a hash reference or object
Like %hashes versus @arrays, these two new types have the advantage that
they can describe both a quantity and a quality. RFC 23, "Higher order
functions" adds a new variable prefix, ^, because it introduces a
fundamental new type: the placeholder. The same idea should apply here
as well.
Consider the above sample code now:
*c = Class-new;
($u, *g) = *c-get_user;
(*d, *f, *j, $m) = *c-read_data;
# ... lots of code passes ...
print "Thanks $u for your ", *g-purchase;
*member = *d || *CLASS_DEFAULT; # oh, they're refs!
OT: pronouncing www (was: Re: ... as a term)
On Thu, 24 Aug 2000, Bart Lateur wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) "The world"? This problem only exists in English! We pronounce it something similar to "way way way". Personally, I've always said it "dub dub dub". Dave
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators =head1 VERSION Maintainer: Markus Peter [EMAIL PROTECTED] Date: 24 Aug 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 143 =head1 ABSTRACT Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. Too special-case to do just 'case'. See the Unicode standard and tech reports about normalization. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 143 (v1) Case ignoring eq and cmp operators
At 10:56 AM 8/24/00 -0600, Tom Christiansen wrote: Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 143 (v1) Case ignoring eq and cmp operators
--On 24.08.2000 10:56 Uhr -0600 Tom Christiansen wrote: The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Depends on taste I guess... Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. With the same argument we can drop -- and ++, and while we're at it, the arithmetic minus in favor of +(-$num). In my consideration, a case-insensitive equality check is a rather common operation in Perl programs so it deserves its own operator. Power derives not from uncountably many special-purpose functions and syntax, but rather from the ability to combine primitive features *algorithmically* to arrive at the desired functionality. The factorial powers of combinatorics put to shame a merely linear increase in the number of available functions. I'd use C then if I'd agree completely with this statement. $a eq/i $b $a cmp/i $b You want ugly, I'll give you ugly. That's ***UGLY***. It's a syntactic anomaly that does not fall out of anything else in the language. The analogy to m//i or s///g is a false one, as those are not functions I still say it looks familiar even if it's a false analogy. Another possibility would be to use cmpi and eqi -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: OT: pronouncing www (was: Re: ... as a term)
The "www" in e.g., "www.netscape.com" is pronounced, IMO, in the same way as other useless, should-be-obvious punctuation. It's silent. Seems like something you should take up with RFC 819, or maybe with RFC 881, considering that they and their ramifying successors all seem to be in flagrant disagreement with you. In short, if foo.bar eq www.foo.bar, someone has high-jacked port 53. --tom
Re: RFC 143 (v1) Case ignoring eq and cmp operators
While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. If you want to treat 1 and -1 as the same, you filter through abs(). If you want to treat a and A as the same, you filter through lc(). In neither case do you go creating new functions, when a generic filter will suffice. It's like making all programs understand some random new switch rather than creating one single filter program that produces the proper transmogrification. It's the Wrong Way. And you certainly don't go creating a brand new syntax! --tom
Re: OT: pronouncing www
At our company, we pronounce "www" as "dub-dub-dub". The first syllable of the letter "w", three times. Very easy to say quickly. "dub-dub-dub-dot-perl-dot-com". Try it. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 143 (v1) Case ignoring eq and cmp operators
We need a way to mix eq, the things to be compared, and the operation
to be done on them before they are compared:
lc{ $foo eq $bar }
$foo eq (lc) $bar
$foo eq{lc} $bar
None of those are like any existing syntax in Perl. The current way:
lc($foo) eq lc($bar)
seems fine in comparison.
I'd say this argues for the parser to be told about new infix operators:
use operator
'eqi' = 'infix';
$blah eqi $bork
# rewritten as eqi($blah,$bork)
This raises another issue, though:
You'd obviously want to have a module that collected together your
favourite new operators. But if they were lexically scoped, they'd
be lexically scoped to the module they were defined in, i.e. your
collection rather than your main program. We're going to have to
think of a way to consistently say "do this in my caller's lexical
scope" without it becoming a nasty upvar hell.
Nat
Upscope (was Re: RFC 143)
Nathan Torkington wrote: We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Perhaps this would work: a way to override (i.e. quash) the behavior that instantiates a new scope on entry to a lexical block, using the current one instead. So that given my $lex = 1; local $loc = 1; noscope require Bar; where Bar.pm contains my $lex = 2; local $loc = 2; $lex and $loc in the caller are both assigned 2, overwriting 1. And any other lexically scoped effects are similarly modified. This would have the advantage of being under the caller's control, and the "upvar" effect is strictly limited to one level, to one specific scope (per use of noscope()). -- John Porter We're building the house of the future together.
Re: RFC 143 (v1) Case ignoring eq and cmp operators
At 11:33 AM 8/24/00 -0600, Tom Christiansen wrote: While I don't know that I'd argue in favor of this feature request, your argument against misses the mark here. It's saying, essentially, that the difference between "P" and "p" is the same as the difference between -1 and 1. That, as they say, turns out not to be the case. The upper and lower-case versions of letters in many languages are essentially equivalent and it's reasonable to want them to be treated the same way when that's appropriate. If you want to treat 1 and -1 as the same, you filter through abs(). If you want to treat a and A as the same, you filter through lc(). As I said, I wasn't arguing for or against the feature, merely pointing out that your argument against wasn't quite on-target. In most human languages, "Please" and "please" are the same word, though that's not the case with computer languages. The numbers 1 and -1 aren't the same, though. Personally I think I'm in favor of Nat's suggestion of allowing the definition of new infix operators and let this be taken care of in a module, but that's just passing the buck. (Not that it's a bad strategy, mind... :) 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]
"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: OT: pronouncing www (was: Re: ... as a term)
"foo.bar" ne "www.foo.bar"
pronounce("foo.bar") eq pronounce("www.foo.bar")
As in, "Surf to www.perl.org and read the new ..."
sounds like
"Surf to perl dot org and read the new ..."
=Austin
--- Tom Christiansen [EMAIL PROTECTED] wrote:
The "www" in e.g., "www.netscape.com" is pronounced, IMO, in
the same way as other useless, should-be-obvious punctuation.
It's silent.
Seems like something you should take up with RFC 819, or maybe with
RFC 881, considering that they and their ramifying successors all
seem to be in flagrant disagreement with you.
In short, if foo.bar eq www.foo.bar, someone has high-jacked port 53.
--tom
=
Austin Hastings
Global Services Consultant
Continuus Software Corporation
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
Re: OT: pronouncing www (was: Re: ... as a term)
Thus it was written in the epistle of Austin Hastings,
"foo.bar" ne "www.foo.bar"
pronounce("foo.bar") eq pronounce("www.foo.bar")
As in, "Surf to www.perl.org and read the new ..."
sounds like
"Surf to perl dot org and read the new ..."
=Austin
Just to be absolutely certain, could you say that again, using www.perl.com
as the example?
Thanks,
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
Science is built up with facts, as a house is with stones. But a collection
of facts is no more a science than a heap of stones is a house.
-- Poincare, Jules Henri (1854-1912)
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote: On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. Next you'll want case)insensitive hashes! Er... actually, that sounds rather useful, even more than your ideas, which can be easily emulated. Suppose you want to keep the case on the hash keys, because you enumerate them. But you still want to find hash entries in a case insensitive manner... tie, TIEHASH, FETCH. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
Merge C$!, C$^E, and C$@
Merging $! and $^E makes perfect sense to me. I don't know why there are
two different error variables. Er... wasn't that three? I'm not
absolutely certain, but I thought there was a third one, too. time
passes... Oh yes: $? AKA $CHILD_ERROR. Throw that in as well.
But $@ is an entirley different beast.
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $@;
$@ contains the whole user provided string, possibly including script
file name, line number and input record number. But $! is just the "file
does not exist" string. Two different things.
--
Bart.
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Bart Lateur wrote: Suppose you want to keep the case on the hash keys, because you enumerate them. But you still want to find hash entries in a case insensitive manner... ...then you simply reach for Tie::CPHash on CPAN! -- John Porter
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote: Damian Conway's Text::Balanced module does a pretty good job of tokenizing Perl code. However, bare C/.../ and C?...? require semantic analyis to distinguish them from division and the hook (CA?B:C) operator. To remove this hassle, and thus permit programs that analyze the source-code of other programs, I propose requiring that all matches require an explicit Cm. Oh. I would have put my hopes on a better (= more generic) O::Deparse mechanism to make Perl analyse the source code for you. Rewriting a Perl in a module seems a bit silly to me. -- Bart.
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
At 10:37 PM 8/24/00 +0200, Bart Lateur wrote:
On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote:
Merge C$!, C$^E, and C$@
Merging $! and $^E makes perfect sense to me. I don't know why there are
two different error variables.
$! eq "No such file or directory"; $^E eq "CD-ROM drive door open" :-)
Er... wasn't that three? I'm not
absolutely certain, but I thought there was a third one, too. time
passes... Oh yes: $? AKA $CHILD_ERROR. Throw that in as well.
Actually I intentionally left it out. But I am starting to think you're right.
But $@ is an entirley different beast.
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $@;
$@ contains the whole user provided string, possibly including script
file name, line number and input record number. But $! is just the "file
does not exist" string. Two different things.
The proposal is that $! would be overwritten with the die string. Reason:
whoever's interested in both $@ and $! at the end of an eval? There was an
error; everyone looks at $@, which almost certainly contains $! if it was
useful. So the above becomes:
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $!; # Contains the user provided string etc
Yes, this is losing information; the former $! is no longer around. I
contend that it's eliding functionality that is seldom, if ever, used, in
favor of a natural simplification. There's one place where an error
message shows up. One. No need to figure out what kind of thing failed.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.
On 24 Aug 2000 20:29:21 -, Perl6 RFC Librarian wrote: Replace first match function (C?...?) with a flag to the match command. Sounds reasonable. I propose "1". ?foo? becomes /foo/1 Eh, no, that looks silly. And, what's so special about the first match? What if I want the second match, or the third? -- Bart.
Re: RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.
Bart Lateur wrote: And, what's so special about the first match? What if I want the second match, or the third? (/foo/g)[2] ??? -- John Porter We're building the house of the future together.
Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types
Tom Christiansen wrote:
You pretend that a reference is not a "true" scalar.
That's certainly not valid. It obviously is.
Well, this is a matter of semantics, pure and simple. Technically, it
is. But I would argue that cognitively it is not by any means.
Especially if a reference points to an array or hash or object, all of
which contain multiple things and properties.
The argument that "it points to one thing" is fallacious, IMO. If we
extend this argument, then @ and % are superfluous and should be
dropped, since they point to single arrays and hashes. But they're not,
and pointing to @ and % with a $ is strange. I'm used to it, but it's
still strange.
I happen to strongly appreciate that the invocant in
$a-blah
can be of either sort; that is:
$a = "MyClass";
$a-blah;
or
$a = MyClass-generate();
$a-blah();
In fact, who knows what generate() returned? It could have
been a class name.
Outstanding point. You're right, this RFC would make not caring about
this impossible. And this is an important issue.
However, consider this in a different light for a moment:
$a = "MyClass";
*a = MyClass-generate; # ask for ref back
$a-blah;
*a-blah; # use our ref
Whether or not having to care about your refs is good or bad depends on
which way you look at it. In one case, it's bad if you don't want to
have to care at all. On the other hand, what if you don't want to care,
and MyClass-generate returns "5"? This probably won't work. So you do
want to care, at least a little, and * helps with this by doing implicit
ref sanity checks for you.
For example, here you know roughly what you're addressing:
$a[0][1] # element of array
$h{key} # element of hash
Why not make that easier still?
print $this # "true" scalar
*a[0]-func # first element (ref) of @a
*h{key}-func # key element (ref) of %h
You can already tell hashes and arrays apart, why not references vs.
simple scalars?
You introduce bizarre *foo[$i] syntax. Why should that be
any different than $foo[$i]?
First, just because it's new doesn't necessarily make it bizarre. :-)
The only syntactic difference between the two is the prefix - * vs. $.
The * is used to explicitly address a reference, just like @ explicitly
addresses an array.
It's also less obtuse that this, since - connotes an "action" to many:
$hash{key} # non-action
$$hash{key} # non-action
$hash-{key} # action??
$*hash{key} # non-action
Some will claim that "dereferencing" is the action. So why doesn't the
second one have a -? This is inconsistent. The use of a * to specify
references makes them explicit and easy to see, instead of inferred.
I'm not arguing this is the solution to the world's problems. What I
*am* arguing is that it's something worth pondering, especially since
there are at least 4 other RFC's claiming that "prefixes are useless"
for the reasons I mention in the RFC. Rather than just saying "drop
'em!", I'm proposing something which I think could potentially improve
their usefulness.
-Nate
Re: RFC 111 (v1) Whitespace and Here Docs
At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote:
Okay, devil's advocate.
Paragraphs.
sub legal {
print FOO
Attention criminal slacker, we have yet
to receive payment for our legal services.
Love and kisses
FOO
}
I'm coming into this a bit late, so forgive me if this is impossible or
already dismissed, but what about
print qr/\s*FOO\s*/
Attention, dropsied weasel, we are
launching our team of legal beagles
straight for your scrofulous crotch.
xx oo
FOO
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types
However, consider this in a different light for a moment:
$a = "MyClass";
*a = MyClass-generate; # ask for ref back
$a-blah;
*a-blah; # use our ref
Whether or not having to care about your refs is good or bad depends on
which way you look at it. In one case, it's bad if you don't want to
have to care at all. On the other hand, what if you don't want to care,
and MyClass-generate returns "5"? This probably won't work. So you do
want to care, at least a little, and * helps with this by doing implicit
ref sanity checks for you.
Perl already does the sanity check for you: "can't call method
without package or reference". What you're saying requires the
programmer to diddle about, which is never a win.
For example, here you know roughly what you're addressing:
$a[0][1] # element of array
$h{key} # element of hash
Why not make that easier still?
print $this # "true" scalar
*a[0]-func # first element (ref) of @a
*h{key}-func # key element (ref) of %h
And just what about that is easier than the good old way. I *know*
what I'm addressing when those are written normally. I'm addressing at
the level of complexity that works.
You can already tell hashes and arrays apart, why not references vs.
simple scalars?
I *can* tell them apart: can't you? If ref...
Beyond that, why should an array of strings be treated differently
from an array of references? This is one of Perl's masterful
unifications. Constrast this with annoying languages where you
have to be overly anal about typing.
You introduce bizarre *foo[$i] syntax. Why should that be
any different than $foo[$i]?
First, just because it's new doesn't necessarily make it bizarre. :-)
The only syntactic difference between the two is the prefix - * vs. $.
The * is used to explicitly address a reference, just like @ explicitly
addresses an array.
When you say @{ ... }, you are specifically "addressing a reference",
as you put it. Likewise when you say $blah-[ ... ].It requires no
extra mollycuddling.
Dollar means one thing -- singular.
At sign means many things -- plural.
(Percent means an assocation of things -- perhaps genitive/possessive.
Now you can have a list of singular things, where you don't have
to get all uptight about whether some of those things are primes,
others are unicode strings, and still others are socket connections.
This is clean and simple.
It's also less obtuse that this, since - connotes an "action" to many:
$hash{key} # non-action
$$hash{key} # non-action
$hash-{key} # action??
$*hash{key} # non-action
It *does*? To whom? And why do we care?
I just don't see any issue here.
--0tom
Re: RFC 111 (v1) Whitespace and Here Docs
I'm coming into this a bit late, so forgive me if this is impossible or already dismissed, but what about print qr/\s*FOO\s*/ Attention, dropsied weasel, we are launching our team of legal beagles straight for your scrofulous crotch. xx oo FOO Rather than print FOO =~ /^\s+(.*\n)/g; Attention, dropsied weasel, we are launching our team of legal beagles straight for your scrofulous crotch. xx oo FOO you mean? --tom
Re: RFC 111 (v1) Whitespace and Here Docs
At 04:30 PM 8/24/00 -0600, Tom Christiansen wrote: I'm coming into this a bit late, so forgive me if this is impossible or already dismissed, but what about print qr/\s*FOO\s*/ Attention, dropsied weasel, we are launching our team of legal beagles straight for your scrofulous crotch. xx oo FOO Rather than print FOO =~ /^\s+(.*\n)/g; Attention, dropsied weasel, we are launching our team of legal beagles straight for your scrofulous crotch. xx oo FOO you mean? Right; I was proposing new syntax for recognizing the terminator; it would not have any effect on the intervening text. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types
Tom Christiansen wrote:
I happen to strongly appreciate that the invocant in
$a-blah
can be of either sort; that is:
$a = "MyClass";
$a-blah;
or
$a = MyClass-generate();
$a-blah();
In fact, who knows what generate() returned? It could have
been a class name.
There is beauty and power in this transparency, which you would see
obliterated. I don't understand that.
Ooh, somebody else to bug about this! And the best example of where this
is really useful that I've seen.
I want to be able to get rid of STRING- dereferencing with a pragma,
for type inferencing purposes. Specifically, $x = $a-blah() requires
"value inference" on $a, which is impossible in general though perhaps
adding all known class names as separate types to the type system will
make it possible some of the time. So I'm trying to collect examples of
where symbolic dereferencing is useful in order to figure out how best
to fence it off and keep it away from those poor sheep.
MyClass-f() is not a problem, of course. How often is nonref $a-f()
useful, and when it is, would
Cmy $a : constraint($a-isa('MyClass') including string values of $a)
ignoring the syntax, be acceptable if you want type-related warnings and
optimizations? (It's still not as good as requiring $a to be a
reference, because concrete type inference will produce the set of
actual subtypes that $a might hold, which may be able to eliminate
virtual dispatch unlike my MyClass $a or somesuch that allows any
subclass. But it's far better than allowing any subroutine named f to be
called, especially with AUTOLOAD lurking.)
And what other uses of symbolic references could you not live without in
a large application where you care about type warnings and type-based
optimizations? (I don't think anyone will want types in one-liners.)
Thanks!
Re: RFC 111 (v1) Whitespace and Here Docs
At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; | Attention criminal slacker, we have yet | to receive payment for our legal services. | | Love and kisses | EOF Others may be focussing on the problem of stripping off leading white space from the here doc contents, but I don't so much care about that because I think the Ram recipes are fine; I'm more concerned about being able to indent the terminator and not have to count spaces in the . Unfortunately the quoting on the terminator following decides the type of interpolation; we're missing a way of indicating how to recognize the terminator other than an exact match. If we say that /\s*FOO\s*/ means terminate on a line matching that pattern, then how can we also say whether we want variable interpolation or not? Which is a pity, 'cos I kinda liked the idea :-) -- Peter Scott Pacific Systems Design Technologies
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; | Attention criminal slacker, we have yet | to receive payment for our legal services. | | Love and kisses | EOF This works for print, but not for other functions where the string is in a single argument, rather than a list. printf( 'EOF' =~ s/^\s*\| ?//g, '[EMAIL PROTECTED]', "Michael Fowler", '400' ); | To: %s | | Hello %s, your payment of $%.2f is late. Please pay now. | | Love and Kisses EOF Though, granted, the example is a little contrived. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: But you don't need that when you can and possibly should just write this: print "EOF" =~ /^\s*\| ?(.*\n)/g; Others may be focussing on the problem of stripping off leading white space from the here doc contents, but I don't so much care about that because I think the Ram recipes are fine; I'm more concerned about being able to indent the terminator and not have to count spaces in the . I was sorta going under the assumption that would cause leading and trailing whitespace to be ignored (not stripped) when looking for the end-of-here-doc indicator. Because whitespace is ignored, I was then proposing some new syntax for stripping whatever one likes from the contents of the here-doc. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, 24 Aug 2000, Nathan Torkington wrote: You'd obviously want to have a module that collected together your favourite new operators. But if they were lexically scoped, they'd be lexically scoped to the module they were defined in, i.e. your collection rather than your main program. We're going to have to think of a way to consistently say "do this in my caller's lexical scope" without it becoming a nasty upvar hell. Not that it adds much information, but this is the lament of RFC 40. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Dan Sugalski writes: Personally I think I'm in favor of Nat's suggestion of allowing the definition of new infix operators and let this be taken care of in a module, but that's just passing the buck. (Not that it's a bad strategy, mind... :) Solve the generic problem, not a specific one. I want to compare case-insensitively" is a specific problem and it's idiocy to go down the road of a special syntax for everyone's different specific problem. Nat
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
Bart Lateur writes: Oh. I would have put my hopes on a better (= more generic) O::Deparse mechanism to make Perl analyse the source code for you. Rewriting a Perl in a module seems a bit silly to me. I don't know enough swear words to say how much I fucking hate the stupid braindead dumbfuck idea that Perl should be the only thing that can tokenize, let alone parse, Perl. It's a great slogan, but a crappy reality. Anything that makes it possible for text editors to understand the syntax of the Perl code in a buffer, for pretty-printers to format Perl, code analysis tools to analyse Perl, etc. *without* requiring those editors, printers, analysers be written in Perl, is a GOOD THING. Read my lips: GOOD THING. I've nothing against dumping the parse tree, but it's not going to solve the problems of pretty printers, editors, code analysers. Nat
Re: RFC 111 (v1) Whitespace and Here Docs
Unfortunately the quoting on the terminator following decides the type of interpolation; we're missing a way of indicating how to recognize the terminator other than an exact match. If we say that /\s*FOO\s*/ means terminate on a line matching that pattern, then how can we also say whether we want variable interpolation or not? Which is a pity, 'cos I kinda liked the idea :-) m'...' vs m"..." (or m/.../ of course) vs m`...` --tom
Re: RFC 111 (v1) Whitespace and Here Docs
I was sorta going under the assumption that would cause leading and trailing whitespace to be ignored (not stripped) when looking for the end-of-here-doc indicator. Because whitespace is ignored, I was then proposing some new syntax for stripping whatever one likes from the contents of the here-doc. I think there's two ideas here in the RFC, one great, the other debateable: 1. Ignore leading/trailing whitespace in here string terminators. All of these should work: EOL EOL EOL # this is the end of the here doc I don't think a special syntax is needed just for this. Make this the default (so "print EOL" does this automatically). If this makes you nervous, use 'This_is_the_end_of_the_string' or some other suitably long EOL marker. 2. That leading whitespace should be stripped off here docs. I am personally against this, for all the reasons everyone has mentioned. It's too specific a "special case". And there's already an extremely easy way to do this (I think TomC posted it again) in Perl 5. That's my($.02). I think #2 should be axed from the proposal. Just focus on #1, because it's a simple yet gracious thing to do, and there's enough edge cases to be considered as-is. -Nate
User-defined quoting operators
A while ago on p5p Joseph Hall allowed as how he would like to have core support for SQL via a construct like qs/SELECT * FROM s_emp WHERE empno IN (101, 343, 573)/ I suggested that one would need to know what database handle it was acting on, and that what made sense (to me) was to overload =~ to bind it to a specific handle, which left open the possibility of a default handle (maybe, the last one opened). IIRC the results would go into a hash via something like bind_columns. I haven't hear any more of this notion since the brief discussion, but this seems like a good time to bring it back up. Now, I don't think the core should be burdened with notions of SQL, but the syntax is most appealing. Conceivably, one could come up with other niche applications where something similar would be equally appealing. So what about the possibility of user-defined q[a-z]// (using a letter that hadn't already been taken), where you get to specify the actions of =~ and probably more operators? Sounds like it has a lot in common with operator overloading - maybe even just an extension to overload.pm? -- Peter Scott Pacific Systems Design Technologies
Re: RFC 127 (v1) Sane resolution to large function returns
I'm missing what you are trying to say. Are you suggesting that $foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ? I wasn't suggesting going that far. Just a little more DWIM. So that ($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef # or # $foo = 1 @bar=(2), $baz = 3 ($foo, @bar, $baz) = (1,(2,3),4) # $foo = 1 @bar=(2,3), $baz = 4 But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) *blech*, I'm glad that you're doing the thinking. chaim "LW" == Larry Wall [EMAIL PROTECTED] writes: LW Chaim Frenkel writes: LW : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW : LW context, as long as the object returned overloads itself to behave as LW : LW arrays and hashes currently do in scalar context. LW : LW : Isn't this an internals issue? LW Not completely. The scalar value would visably be a built-in object: LW @bar = (0,1,2); LW $foo = @bar;# now means \@bar, not (\@bar)-num LW print ref $foo, $foo-num, $foo-str, ($foo-bool ? "true" : "false"); LW ^D LW ARRAY3(0,1,2)true LW One implication of this approach is that we'd break the rule that says LW references are always true. Not clear if that's a problem. It's basically LW already broken with bool overloading, and defined still works. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: August 20, 2000 Last Modified: August 24, 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 135 =head1 ABSTRACT C?...? and C/.../ are what makes Perl hard to tokenize. Requiring them to be written Cm?...? and Cm/.../ would solve this. =head1 CHANGES Version 2 of this RFC redirects discussion of this topic to [EMAIL PROTECTED] =head1 DESCRIPTION Damian Conway's Text::Balanced module does a pretty good job of tokenizing Perl code. However, bare C/.../ and C?...? require semantic analyis to distinguish them from division and the hook (CA?B:C) operator. To remove this hassle, and thus permit programs that analyze the source-code of other programs, I propose requiring that all matches require an explicit Cm. =head1 IMPLEMENTATION Remove the bare C/.../ and C?...? from the grammar :-) When converting perl5 programs to perl6, put the Cm in. =head1 REFERENCES perl6-language message C[EMAIL PROTECTED] by Damian Conway
RFC 156 (v1) Replace first match function (C?...?) with a flag to the match command.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace first match function (C?...?) with a flag to the match command. =head1 VERSION Maintainer: Stephen P. Potter [EMAIL PROTECTED] Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 156 =head1 ABSTRACT The first match function should be removed from the language and its functionality should be implemented via a flag to the standard match function. =head1 DESCRIPTION The syntax of the first match function is a special case anomoly which causes the parser to have to work harder. Removing its special syntax would simplify the language definition and make writing parsers easier. =head1 IMPLEMENTATION It is recommended that the flag be Cf, which is a mneumonic for "first". Additionally, the code for the parser which checks for C?...? should be removed from the grammar. =head1 REFERENCES perl6-language message C[EMAIL PROTECTED] by Damian Conway RFC 135: Require explicit m on matches, even with ?? and // as delimiters.
Re: RFC 143 (v1) Case ignoring eq and cmp operators
I want four special new comparison operators. Firstly, " e q " That is, an operator that ignores any leading, any trailing, and treats all intraspace as equivalent. If the embedded space is confusing, I may consider suggesting an operator modifier, "/ ". Secondly, Eq, which operates only the so-called dictionary order, that is, ignoring all non-alphabetic characters (and case). I will possibly also want Cmp which will sort "foo200" before "foo1000". Thirdly, I want ==/R which will know that "v" is equal to 5, I need to keep my lists of Popes in good order. Fourthly, I want eq/multinlingual since I simply need to have "jouluaatto" eq "Christmas Eve" -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 127 (v1) Sane resolution to large function returns
At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't that be $baz = 3, since the middle list would be taken in scalar context? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 127 (v1) Sane resolution to large function returns
Dan Sugalski [EMAIL PROTECTED] writes: At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't that be $baz = 3, since the middle list would be taken in scalar context? Which has sanely become the length of the list rather than last element. -- Nick Ing-Simmons
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Case ignoring eq and cmp operators =head2 Problems with current ways to do it Perl currently knows basically two methods for checking of equality of strings case-insensitively: uc($a) eq uc($b) $a =~ /^$b$/i and for comparing them one: uc($a) cmp uc($b) The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. That makes little sense, as I'm sure you'll agree. Similarly, so too does the desire to have a new eq operator seem exceedingly misplaced. Power derives not from uncountably many special-purpose functions and syntax, but rather from the ability to combine primitive features *algorithmically* to arrive at the desired functionality. The factorial powers of combinatorics put to shame a merely linear increase in the number of available functions. Of lesser but not inconsequential importance is that it is easier on everyone if they don't have more distinct functions and syntax to remember. Would it really be better to have a -==- operator than for people to remember to use == with abs? Of course not. A programmer learns to use the tools in hand to create new things. $a eq/i $b $a cmp/i $b You want ugly, I'll give you ugly. That's ***UGLY***. It's a syntactic anomaly that does not fall out of anything else in the language. The analogy to m//i or s///g is a false one, as those are not functions, and do not syntactically take argument in the same way. Nothing else in Perl looks this way. --tom
Re: RFC 127 (v1) Sane resolution to large function returns
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Dan Sugalski writes: LW : And do we want to consider making this (and its ilk) Do The Right Thing? LW : LW :(@foo, @bar) = (@bar, @foo); LW We certainly want to consider it, though perhaps not in -internals. LW You can talk about passing @bar and @foo around as lazy lists, and LW maybe even do lazy list-flattening, but I don't see how that works yet, LW even in the absence of overlap. The basic issue here may come LW down to whether the LHS of an assignment can supply a prototype for the LW entire assignment that forces everything to be treated as objects LW rather than lists. LW That is, right now, we can only have a scalar assignment prototype of ($), LW and a list assignment prototype of (@). We need a prototype (not just LW for assignment) that says "all the rest of these arguments are objects", LW so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@). LW Or (\@*) for short. Isn't that what Damian's named (whatever, formerly known as prototypes) does? @_ in the absence of a named argument list would continue to act _as if_ the argument list were flattened. With a named argument list, it would make the actual refs on the stack visible. The question that I think Dan proposed is how much breakage would infering (@foo, @bar) = (@bar, @foo) to mean treat RHS as objects, cause. Wouldn't having and @ anywhere but the last position in the list would be a useful indicator. I can see someone (Probably Randal or Tom) wanting to initialize a list that way. But for the rest of us, it isn't that useful. LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW context, as long as the object returned overloads itself to behave as LW arrays and hashes currently do in scalar context. Isn't this an internals issue? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 127 (v1) Sane resolution to large function returns
Chaim Frenkel writes: : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar : LW context, as long as the object returned overloads itself to behave as : LW arrays and hashes currently do in scalar context. : : Isn't this an internals issue? Not completely. The scalar value would visably be a built-in object: @bar = (0,1,2); $foo = @bar;# now means \@bar, not (\@bar)-num print ref $foo, $foo-num, $foo-str, ($foo-bool ? "true" : "false"); ^D ARRAY3(0,1,2)true One implication of this approach is that we'd break the rule that says references are always true. Not clear if that's a problem. It's basically already broken with bool overloading, and defined still works. Larry
Re: RFC 151 (v1) Merge C$!, C$^E, and C$@
On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote:
But $@ is an entirley different beast.
The proposal is that $! would be overwritten with the die string. Reason:
whoever's interested in both $@ and $! at the end of an eval? There was an
error; everyone looks at $@, which almost certainly contains $! if it was
useful. So the above becomes:
eval {
open ",^#!" or die "Cannot open file: $!"
};
print $!; # Contains the user provided string etc
Yes, this is losing information; the former $! is no longer around. I
contend that it's eliding functionality that is seldom, if ever, used, in
favor of a natural simplification. There's one place where an error
message shows up. One. No need to figure out what kind of thing failed.
There's a whole in your logic.
eval {
open "some_name_for_a_file_that_does_not_exist";
undef;
}
The eval will not fail ($@ not set), but $! will be set to something
like "file not found".
eval {
open "some_name_for_a_file_that_does_not_exist"
or die "Hoorible death: $!";
}
Now, as it is now, $@ *will be set, to the complete error message. $!
will be set, too.
$@ is *the* marker that something died inside the eval. You can't test
eval's return value: both examples return undef. $! is unreliable --
unless you're proposing that $! would be cleared at the end of the eval
block, if it doesn't fail (as is pretty much the case with $@ now).
--
Bart.
Re: RFC 111 (v1) Whitespace and Here Docs
On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote:
I thought this problem would've been neatly solved by my proposed:
print "FOO" =~ s/^ {8}//;
Attention criminal slacker, we have yet
to receive payment for our legal services.
Love and kisses
FOO
The result of substituting the leading 8 blanks (which might be tabs!)
from the very front just once is probably 1, which isn't a very interesting
thing to print. :-(
Oh, well, there should have been a /g there. And the regex may not work for
everyone (it would work wonderfully for me). If you like:
print "EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
Basically, it's shorthand for the current syntax:
$message = "EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
print $message;
But any inconsistencies or errors in my examples should not detract from the
general idea.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 111 (v1) Whitespace and Here Docs
Basically, it's shorthand for the current syntax:
$message = "EOF" =~ s/^\s*\| ?//g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
print $message;
But any inconsistencies or errors in my examples should not detract from the
general idea.
But you don't need that when you can and possibly should just write this:
print "EOF" =~ /^\s*\| ?(.*\n)/g;
| Attention criminal slacker, we have yet
| to receive payment for our legal services.
|
| Love and kisses
|
EOF
{--tom
