Re: On the case for exception-based error handling.
--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
This probably won't work. What would you return exactly? Also, there's
plenty of chance that the return value could interfer with the regular
return values of that function... This will never be possible without
work done by the module author so the return value plays nicely.
...
Hence, exception handling (with or without catch phrases) allows the
normal, non-error case to be coded more simply both when you don't care
about catching errors (die), and when you do.
Hmm.. I don't know how this paragraph relates to my comments (even though
it's a nice overview of the advantages from exceptions - which I'm already
convinced of after being forced to program in Java for several years.) What
I was talking about is that I cannot imagine that the perl core itself
magically transforms exceptions into return values as someone else
requested.
"enabling/disabling fatality for exceptions with a pragma"... if the idea
is that control continues linearly past a throw, then sub/module authors
must write twice the error handling logic, which is painful. If it means
No - the sub returns as if it has correctly thrown the exception, but if
the exception really propagates to the top most level, it will be ignored
instead of die'ing. This is really the same as a try/catch block around my
whole program just not that ugly.
that the destination of the throw is bounded to some boundary, that
boundary must be defined... so I guess that's a scoped pragma, so the
syntax would be something like
{ use no_fatal_throws;
ignore_my_errors ( @params );
}
That's just about exactly the same length and complexity as the null catch
phrase above, which does exactly the same job.
What I was actually requesting was a small pragma which simply turns off
all fatality, in the whole program, similar to what $SIG{__DIE__} currently
is able to do, without the need to span a try/catch block across my whole
main program - I simply do not like the look and feel of that. Even though
this has global effects, it's not necessarily evil, we should only ensure
that it cannot be used from within a .pm
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Re: RFC 88: Possible problem with shared lexical scope.
Peter Scott wrote: Given that even though we know the shared scope could be implemented, the implementors may prefer not to do it. I would therefore reword: We would prefer that the blocks share a common lexical scope in the way that Ccontinue blocks used to; if this is deemed inappropriate, this feature can simply be deleted, and the outer scope can be shared. I added the following to RFC 88 + ISSUES + Lexical Scope: The authors would prefer that try, catch, and finally blocks share the same lexical scope. Yours, c, Tony Olekshy
Re: On the case for exception-based error handling.
At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote: Peter Scott wrote: I actually see nothing wrong in division returning undef for a dividend of 0. It's just as easy to check as doing an eval. Please don't do this. I would have to check every divide in all my code, since no fatal is the default! Leave the current version of Perl's best guess as to what it should die on alone, unless use fatal is in scope. Consider this: $amount_i_owe_you = $gross_amount / $discount_rate - $paid; If $discount_rate is accidentally undef and $paid is $100, then the $amount_i_owe_you is now -$100. I don't see my cheque yet ;-) But surely you have to be consistent. I understood Chaim's point to be that he wanted no exceptions if he didn't ask for them. If the core currently dies where it could return and set $!, then it is being inconsistent, since this is not an error that prevents perl from continuing. How can Chaim or anyone else write a program and know that it won't die if we allow such things to continue? I suppose we could have a use Fatal qw/legacy/ Yuk. -- Peter Scott Pacific Systems Design Technologies
Re: On the case for exception-based error handling.
On Tue, 22 Aug 2000, Glenn Linderman wrote: I'm suddenly intuiting that maybe you want to continue execution after the sub call that caused the throw. But if you continue, you won't have the return values from the sub call. Where should the continuation take place for something like: l1: $a = foo ( bar ( $b )); l2: baz ( $a ); l3: in the two different cases that bar throws, and that foo throws? If you continue "immediately after" the sub call, and bar throws, foo is likely to get bad parameters and also fail. And if you say the next statement after a Yes, that's true, but I'm not talking about such cases. Your above example would result in garbage in, garbage out which is ok if I want to circumvent the exception system. Maybe it's easier to understand if I explain what I do not want to have ;-) I'd normally use such a pragma when I want to write a small hack, not a large project. What I fear are that certain modules will die on me even on stuff comparable to e.g. unlink in side effects - as they simply want to throw an exception as a means of reporting "file is not there anyway" - which I absolutely do not care about... E.g. in Java writing small hacks is impossible because you'll spend half your time adding try/catch blocks around stuff... Perl is a bit better in that respect - it allows me the choice to forget completely about exceptions or having the same trouble as in Java What I request is probably similar to the no Fatal pragma someone proposed. The only thing I dislike about no fatal is that modules are supposed (are they really?) to return error return values then - and what I'd like to have is still that I CAN catch exceptions at some points, but I need not to. If I don't check it, I'll simply get an undef return value, but I still have the choice to check one or two possible exceptions without enabling/disabling all that myself. The current definition of use fatal/no fatal would not allow this I think as suddenly those modules could stop throwing exceptions, so I'd end up enable/disabling use fatal all the time... Another way to achieve the same result would be to NOT get rid of the try part of try/catch and then try automatically implies use fatal for that block... -- Markus Peter [EMAIL PROTECTED]
RE: On the case for exception-based error handling.
[snip] -Original Message- From: Markus Peter [mailto:[EMAIL PROTECTED]] Another way to achieve the same result would be to NOT get rid of the try part of try/catch and then try automatically implies use fatal for that block... -- Markus Peter [EMAIL PROTECTED] [/snip] So that was: Any exception raised in a try will be fatal unless caught? -Corwin
RE: On the case for exception-based error handling.
At 04:06 PM 8/22/00 -0500, Brust, Corwin wrote: [snip] -Original Message- From: Markus Peter [mailto:[EMAIL PROTECTED]] Another way to achieve the same result would be to NOT get rid of the try part of try/catch and then try automatically implies use fatal for that block... So that was: Any exception raised in a try will be fatal unless caught? It already is (RFC 88). -- Peter Scott Pacific Systems Design Technologies
Re: On the case for exception-based error handling.
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS From the reactions on this thread so far I am wondering whether the
PS message I sent out about it when it had a different name got
PS through. Relevant excerpt:
PS Well, you could certainly have a pragma that makes throw set $! to the
PS message and does a return undef. But that will only return from the
PS current subroutine; there could be a bunch of module subroutines between
PS that one and the module user. Asking module programmers to keep straight
PS two possible flows of control in error situations, no less, is asking for
PS trouble. If you think it can be made easier, can you show an example?
Actually, why not simply unwind the call stack to the routine that
has the pragma active.
sub foo {use exception; baz()}
sub baz { throw "a fit" }
sub bar {
no exception;
foo();
}
The unwind logic would treat a scope with no exception set _as if_
each call were wrapped in at try block.
PS ***But it's entirely up to each programmer whether or not they use
PS Fatal-checking*** This is the Perl way anyway.
Fatal checking, is for core functions. And optional for module authors.
Then Fatal.pm and exception.pm could possibly be consolidated.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: On the case for exception-based error handling.
Chaim Frenkel wrote:
Actually, why not simply unwind the call stack to the routine that
has the pragma active.
sub foo {use exception; baz()}
sub baz { throw "a fit" }
sub bar {
no exception;
foo();
}
Yes.
The unwind logic would treat a scope with no exception set _as if_
each call were wrapped in at try block.
I don't think so. If no exception is in scope Perl should continue
to generate and propagate exceptions (die and $@) as it does now,
so we don't break tradition.
PS ***But it's entirely up to each programmer whether or not they use
PS Fatal-checking*** This is the Perl way anyway.
Fatal checking, is for core functions. And optional for module authors.
Yes.
Then Fatal.pm and exception.pm could possibly be consolidated.
Yes.
I like something like this
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 137 (v1) Overview: Perl OO should Inot be fundamentally changed.
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
=item *
Changes to the semantics of Cbless so that, after associating an
object with a class, the class's CINIT methods are automatically
called on the object. An additional trailing C@ parameter for
Cbless, to allow arguments to be passed to CINIT methods.
Ooh:
sub INIT {
$ME-_init unless $ME-initialized;
my $tok = $ME-parser-next_token;
my $next_state = $ME-handle($tok);
bless $ME = $next_state;
}
That OO state machine idea I keep toying with gets more and more
scary. Of course, the call stack could get rather deep...
--
Piers
Re: RFC 137 (v1) Overview: Perl OO should Inot be fundamentallychanged.
On 8/22/00 12:45 AM, Uri Guttman wrote: perl could be the uber OO language, capable of emulating ANY object style. Is this more important than improving performance vs. Perl 5 OO? Not IMO; I want speed. Hey, if I can have both, I'm all for it. But if forced to choose... -John
Re: RFC 95 (v2) Object Classes
Hildo Biersma [EMAIL PROTECTED] writes: =head2 Inheritance As with the existing Cuse base/Cuse fields pragmata, Perl 6 classes should support single, linear inheritance only. Multiple inheritance is generally more trouble than it's worth. Yuck. MI is useful though sometimes abused, and even (cough) Java supports multiple inheritance of interfaces. There is existing perl5 code using mulitple inheritance that we should be able to support in perl 6. Multiple inheritance is useful for 'mixins'. For example Tk has a 'mixin' class Tk::Wm which is used as a prefix to the @ISA list of widgets which are "toplevels" and thus should respond to methods relating to the "Window Manager". These "mixin" classes typically add extra methods which are defined in terms of methods of the "core" object. As such they do not _usually_ require attribute space in the object. -- Nick Ing-Simmons
Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-likewith or express
Nathan Torkington wrote:
# making this part up
struct Person = [ qw(Name Age Height Weight) ];
# but once you have a named structure, you can say ...
my Person %nat;
with (%nat) {
$Name = "Nathan"; # rewritten to $nat{Name} at compile-time
...
}
It's kinda like fields.pm only for real hashes not pseudohashes.
Nat
okay but we still have the hiding issue, in case we want it to
work with arbitrary hashes as well as defined structures: a neat
trick if we can do it, and we can. In that case, the hiding properties
are not just one more thing to keep track of but become a
security issue analougous to having . early in yout $PATH variable.
Therefore a way to indicate "this is near the end of a record name"
is required. Dot already means too much (although is it defined
between barewords? It might work, it works elsewhere) so I used \
in the way of the directory indicator from DOS, and in an allusion
to unary \ as the reference-of operator.
And you dont have to make sure the $s on the left of the names match
the {}s on the right, just use one $ and string the names together with
backslashes. This is not easier?
$one{two} is $one\two
$$one{two}{three} is $one\two\three
$$$one{two}{three}{four}is $one\two\three\four
If we have _that_ already,
with %one\two {
push @\three\four, 5,6;
}
is clear and invulnerable.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-likewith or express
David L. Nicol writes:
okay but we still have the hiding issue, in case we want it to
What's the hiding issue? I must have missed that.
$one{two} is $one\two
$$one{two}{three} is $one\two\three
$$$one{two}{three}{four} is $one\two\three\four
Your left hand side is, I think:
$one-{two}{three}{four}
in a very complicated fashion. I'm unsure this is what you meant.
with %one\two {
push @\three\four, 5,6;
}
is clear and invulnerable.
Except that you often don't know the keys in advance, and so now
your code turns into:
with %one\$keytwo {
push @\$keythree\$keyfour, 5, 6;
}
which is decided sub-clear. The precedent of "if you're doing a hash
lookup, use {} around the key" is fairly well-ingrained in Perl.
Nat
Re: $ME in a method called as a subroutine
Markus Peter wrote: ... then I run into trouble if the method author does not even know wether its procedural or OO. What I wrote is dependent on an environmnet where the Cmethod keyword is used to write methods that are distinct from subroutines, and also, a Csub with the same name could be written, causing the sub to be called in procedural-style accesses. Distinguishing methods from subroutines syntacticly is trivial, we already knows what happens when a procedure is called as a method. So if the author wants to distinguish he can write both versions! One will probably generally wrap something up and call the other.
Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-likewith or express
David L. Nicol writes:
Do either of those expressions make sense in terms of
references to something? If not, then syntactically we
are in the clear. They don't, because currently it makes
no sense to butt a reference up to the LHS of anything.
It isn't any less clear than, for instance
$fiename = "C:\$keythree\$keyfour"
Once again you show some code that doesn't work the way you seem to
think it does. You just made the string
'C:$keythree$keyfour'
I don't care how "ingrained" the concept of wrapping the
field names in curlies is, I still think it sucks, and so does anyone
who arrives here after using a language where there is a character (which
is conventionally dot) between the record name and a field in it.
I wrote a long response to this, but finally realized that my biggest
objection is that I think using a backslash sucks. You think curlies
suck. I think backslashes suck. You aren't proposing removing the
curlies from the rest of Perl, so what you're proposing is an
inconsistent-with-the-rest-of-Perl modification to the syntax to
suit your own tastes.
I'm all for learning from other languages, but it has to be consistent
with the rest of Perl.
I'd be more receptive to something that reuses existing or similar
Perl syntax (e.g., extend -).
So in my opinion, you haven't really come up with a strong argument
against:
$foo-{first}{second}{third}
I can't stop you RFCing it, but I definitely think you're heading down
the wrong path.
Nat
Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default
J . David Blackstone [EMAIL PROTECTED] writes: I may be making a bad assumption here, but since a package is usually (but not always) defined one per file, I'm assuming that in several of these places where you said "package" we should perhaps think "file." It is common practice in perl5 to do both of these: A. Multiple packages in one file, using lexicals at file scope to communicate bewteen them. B. Package split accross multiple files (classic case being AUTOLOADed subs) with package variables to communicate between the parts. You need to be able to represent both schemes to tanslate perl5 code (but it can be "moderately awkward" to discourage new weirdnesses). -- Nick Ing-Simmons
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"] Looks like a case for automatic dereferencing! Which Perl has always stated it would _never_ do. Well, this could be the time of changes. -- Johan
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
Looks like a case for automatic dereferencing!
Which Perl has always stated it would _never_ do.
Kinda.
To be honest, Perl does do autoderef in at least two places.
1.
$fh = *FH;
$fh = \*FH
can be used equivalently, because a typeglob ref is autodereffed
as need be in I/O operations. (Not to mention *FH{IO}, even.)
2. bless doesn't bless the reference passed, but its underlying referent,
doing an autoderef to find the referent.
and maybe
3.
$glob = 'SYM';
$glob = *SYM;
are equivalent.
--tom
Re: ... as a term
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimension.
you can also say:
a[10:20,...,10:30,30]
etc.
Karl
Larry Wall wrote:
If you're into dwimmery, you could make all of these work, too:
print (1, 2, 4, ...)
print (1, 4, 9, 16, 25, ...)
print (1, 1, 2, 3, 5, ...)
print ('a', 'b', 'c', ...)
print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
: BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)
If you want to save the world, come up with a better way to say "www".
(And make it stick...)
Larry
Re: ... as a term
On Tue, Aug 22, 2000 at 09:49:12AM -0400, John Porter wrote: Damian Conway wrote: Easy. I'll just add a Cthing operator to Q::S. It would take no arguments and return a (lazy?) list of every possible Perl subroutine. PS: Can you tell whether I'm joking? I think you're both joking AND not joking, at the same time. s/at the same/in constant/; # HTH -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: ... as a term
Piers Cawley wrote: You forgot: print (1, 11, 21, 1211, ...) print( 'M', 'MI', 'MIU', ... ) ALso, Larry, how about making the various common emoticons meaningful? please do come from 10; :-) I.e. "belay that command". -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more liberal
Casey R. Tweten wrote:
sub func {
return qw/KeyOne Value1 KeyTwo Value2/;
}
print "$_\n" foreach keys func();
Please. There are ways -- well, just one way -- to do this, even in perl5.
print "$_\n" foreach keys %{{ func() }};
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Monday AD Reply-to: [EMAIL PROTECTED] Return-receipt-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Tue, 22 Aug 2000 10:15:48 EDT From: Jerrad Pierce belg4mit So, you're saying to dispense with prototypes, even in the core, and leave us with the slowest language known to man? No and no. If you have internal prototypes, why can't it attempt a type conversion IFF you didn't satisfy the prototype. It's like doing math with strings, it checks to see if it really can use it as a number first... Why is this so hard? So the internals stay almost the same, but before resorting to die, you attempt a cast, if it works you warn that's inefficient under strict, and of course in the docs. If I occasionally want to be inefficient, I should have the license to do so. But I really don't think it'll be that less efficient, considering the alternative is to do the casting myself, which will almost certainly use more memory, and run slower than anything in the core. No? I don't see that flying. All it requires is forgetting to hit the ground. -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166: "God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more liberal
Today around 10:11am, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
:
: sub func {
:return qw/KeyOne Value1 KeyTwo Value2/;
: }
:
: print "$_\n" foreach keys func();
:
: Please. There are ways -- well, just one way -- to do this, even in perl5.
:
: print "$_\n" foreach keys %{{ func() }};
Yes, there is.
Thank you for your input.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: Things to remove
Damian Conway wrote: Tom's opcode dumping functionality could, in principle, be added to Data::Dumper as it stands. My proposal was merely that CData::Dumper::Dumper body-snatch Cdump. But that's a crummy name for it, unix legacy not withstanding. Is someone working on an RFC? IIRC, it would propose that the entire state of the interpreter can be marshalled and unmarshalled, providing both a checkpointing capability and code mobility. Optionally the marshall will include only the explicitly given structures (subroutines, variables); or perhaps only a selected subset of interpreter state (code, data). -- John Porter We're building the house of the future together.
Re: Things to remove
Tom Christiansen wrote: Hmm, what about CHECK blocks? CHECK blocks would be great! But of course, they work in memory, which is not useful for persisting program state across executions, or moving it across machines. -- John Porter We're building the house of the future together.
Re: ... as a term
Larry Wall wrote: I'd entertain a proposal that ... be made a valid term that happens to do nothing, so that you can run your examples through perl -c for syntax checks. Or better, make it an official "stub" for rapid prototyping, with some way of getting a warning whenever you execute such a stub. Has anyone done an RFC on this yet? If not, I'll volunteer. -- John Porter
Re: ... as a term
John Porter writes: : Could you make it "evaporate" and compile time, just like the (proposed) qc()? Hard to make it evaporate at compile time and still give a warning at run time. :-) Larry
Re: ... as a term
Larry Wall wrote: John Porter writes: : Could you make it "evaporate" and compile time, just like the (proposed) qc()? Hard to make it evaporate at compile time and still give a warning at run time. :-) Eh, eh... Curdle it into the appropriate warn() call! -- John Porter
Re: functions that deal with hash should be more libera
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 11:06:21 EDT
From: Jerrad Pierce belg4mit
It will show that you are doing what you *want* to do, not letting
automagic error-blind spoofery behind the curtains flummux up
your life unnecessarily.
Umm no.. for what I *want* to do is take the keys of the hash returned as a
list by a block. That's what I want. And yes I can do it with %{{}}.
But it's hardly symmetrical to working with arrays, and definitely not
obvious. Especially to a newbie, and even to lightly seasoned veterans.
How is it error-blind? Someone proposed that it complain if the cast was
performed on an odd-element list. But even that could be valid (the last key
has undef as a value). And I proposed making strict catch this. What other
errors might there be?
Whatever happened to making easy things easy, out of the box?
And if I want to be a masochist and have my code scrutinized like hell,
using strict, -wT ?
use strict 'hash';
no strict 'hash';
--
* __* .
\ | / .. . . . ((_
_ . . .
-- / \ -- .. . +. . _/\
oo. | * . . . * / ;M\_ .
..oo. . .. . /\. / :IMM\
....oo. Jerrad Pierce /\ / \ / ;IIWMM
..oo... 209 North Street +/ \ / \ . / ;WM
...o... Randolph, MA 02368/ \ \ ___/ :;IWM
oooo.../\\ / :: ;;IIIMI
.ooo.http://www.pthbb.org /\ \ : :::;IIIM
..ooo __ || || ::.::
MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166:
"God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more libera
Today around 11:06am, Jerrad Pierce hammered out this masterpiece:
: It will show that you are doing what you *want* to do, not letting
: automagic error-blind spoofery behind the curtains flummux up
: your life unnecessarily.
:
: Umm no.. for what I *want* to do is take the keys of the hash returned as a
: list by a block. That's what I want. And yes I can do it with %{{}}.
: But it's hardly symmetrical to working with arrays, and definitely not
: obvious. Especially to a newbie, and even to lightly seasoned veterans.
Hear, hear! Do What I Mean.
: Whatever happened to making easy things easy, out of the box?
: And if I want to be a masochist and have my code scrutinized like hell,
: using strict, -wT ?
:
: use strict 'hash';
: no strict 'hash';
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: functions that deal with hash should be more libera
Jerrad Pierce wrote:
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 11:06:21 EDT
From: Jerrad Pierce belg4mit
Please stop doing this.
And for God's sake get rid of that obnoxious .sig.
Umm no.. for what I *want* to do is take the keys of the hash returned as a
list by a block. That's what I want. And yes I can do it with %{{}}.
But it's hardly symmetrical to working with arrays, and definitely not
obvious. Especially to a newbie, and even to lightly seasoned veterans.
I think you are still confused as to the difference between arrays and
hashes, which are variables, and lists, which are not.
The assignment of lists to arrays and hashes are well-defined operations,
and quite transparent. Also feeding the confusion is that some array
operations also work on lists, such as scalar() and ()[]. But lists
are still not arrays; and certain array operations can ONLY work on
arrays, because they must work on variables, which lists are not.
Symmetrically, hash operations must work on hashes, which lists are not.
But I do agree it would be nice if there were a way to simultaneously
construct and dereference an anonymous array or list, perhaps something
like
@( 1, 2, 3 )
%( foo = 1, bar = 2 )
which would be equivalent to
@{[ 1, 2, 3 ]}
%{{ foo = 1, bar = 2 }}
but with perhaps lower overhead.
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
But I do agree it would be nice if there were a way to simultaneously
construct and dereference an anonymous array or list, perhaps something
like
@( 1, 2, 3 )
%( foo = 1, bar = 2 )
which would be equivalent to
@{[ 1, 2, 3 ]}
%{{ foo = 1, bar = 2 }}
but with perhaps lower overhead.
You're working too hard.
[ 1, 2, 3 ]
{ foo = 1, bar = 2 }
as in
$name = 'foo';
$value = { foo = 1, bar = 2 }-{$name};
Not that I'm claiming this is excessively efficient, but
it's already there. One just works on the compiler to
be smarter on optimizing. Or the programmer:
$table = { foo = 1, bar = 2 }-{$name};
$name = 'foo';
$value = $table-{$name};
--tom
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Tuesday AD Reply-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Tue, 22 Aug 2000 12:58:38 EDT From: Jerrad Pierce belg4mit I think you are still confused as to the difference between arrays and hashes, which are variables, and lists, which are not. Lists are what the CORE or a subroutine throw back at you. Arrays and hashes are user data structures. Often, arrays and lists can be treated similarly, if not the same. Not so hard to get. The assigment operator can do explicit list to array or hash conversion, I'm just proposing that there be the ability for an implicit conversion when calling a function with a list. Other than the issue of semantics (array is not list), I still have not seen: a) why this is the Wrong Thing b) while not the Wrong Thing, it should not be done. c) something to refute Do What I Mean -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166: "God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more liberal
Other than the issue of semantics (array is not list), I still have not
seen:
a) why this is the Wrong Thing
Why what is the wrong thing? Why treating an immutable list
as a mutable array is wrong? Because you can't change the length
of a list -- it doesn't have an AV to update. If you want
$n = pop fn()
you are just obfuscating writing
$n = (fn())[-1];
b) while not the Wrong Thing, it should not be done.
It should not be done because it is wrong to lose compile-time
type checking save under grave environmental stress, the likes
of which you are yet to demonstrate. The burden of proof rests
with you to show why to turn perl dumber.
c) something to refute Do What I Mean
You have yet to show what you mean, or that what you mean is
painful to accomplish.
There are real issues, but you've missed them. One is the
cumbersomeness of writing
while ( ($k,$v) = each %{ $x[$i][$j] } ) {}
instead of:
while ( ($k,$v) = each $x[$i][$j] ) {}
But that comes with similar attendant problems. What then
should
while ( ($k,$v) = each fn() ) {}
do? How often should fn() be called there? And what if it
returns a hash ref versus a list? What about a list of one
hash ref?
Comflating values with variables is not always sensible: consider
4++, for example; this isn't (old) FORTRAN. :-) Why you should be
able, without a whit of added notation to that effect, to pop a
function return list or each a function return list is not something
you have efffectively proven.
Catching errors is important. The dweomer you would claim desirable
is slippery magic at best, more complex than I think you think.
--tom
Re: functions that deal with hash should be more libera
Tom Christiansen wrote:
it's already there. One just works on the compiler to
be smarter on optimizing.
I suppose that's true. But why would
%( foo = 1, bar = 2 )
be "working harder" than
%{{ foo = 1, bar = 2 }}
??? It's few keystrokes and would be a less tricky concept
to remember.
--
John Porter
Filtering rules
(Off-topic for this list, but I'm not sure where else to send it)
Could we have a discussion somewhere of useful filtering rules for all
these perl6 lists? Specifically, I'm looking to steal other people's
.procmailrc snippets. I imagine that a lot of people have written their
own, and everything I do in that @#$!! config language breaks the first
four times I try it (partly because my mail directory is NFS mounted in
a place where NFS locks permanently hang any process attempting to use
them).
Ask posted a very nice rule to perl6-announce:
=for procmail
I added another header to the perl6-all mails. X-Mailing-List-Name
will contain the original list name, san -help and whatnot.
So the recommended procmail filter rule would now be:
:0:
* ^Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
* ^X-Mailing-List-Name: \/(.*)
perl/$MATCH
or something like that.
Enjoy,
- ask
=cut
(perhaps there is a discussion on perl6-all, which I do not subscribe
to?)
Just for perl6-language, I use:
=for procmail
:0:/tmp/sfink.locks/language.lock
* ^[EMAIL PROTECTED]
{
SUBJECT=`formail -xSubject:`
:0 c
* ^TOsfink
| formail -f -i "Subject: (COPY) $SUBJECT" $HOME/mbox
:0
perl6-language
}
=cut
That's so if anyone is replying to a message I posted deep in some
subthread, I don't miss it (because I *always* read the group threaded;
the traffic would overwhelm me otherwise.) But I probably have the locks
backwards or something.
I think I may have to subscribe to the firehose (perl6-all) and use
something closer to Ask's filter, though.
Can someone tell me how to fetch a digest of an existing subgroup and
split it into separate messages? I know, there are examples that do
things like this, but I'm hoping to be lazy and just steal someone
else's working rule.
Thanks!
Re: functions that deal with hash should be more liberal
In 42 lines, of which 25 were waste, Jerrad Pierce wrote: a) why this is the Wrong Thing It is simply not the way perl works. In these matters at least, perl is quite consistent. c) something to refute Do What I Mean DWIM is cutesy, but not actually meaningful. Perl comes closer to dwim than most any other language, but dwim is not really a perl goal. Instead, you should persuasively explain why your proposed change significantly furthers perl's real goal of making easy things easy and hard things possible. You already have a way of constructing and dereferencing (accessing) an anonymous hash on the fly; what else do you need? -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more liberal
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 13:48:36 EDT
From: Jerrad Pierce belg4mit
$n = pop fn()
you are just obfuscating writing
$n = (fn())[-1];
yes
It should not be done because it is wrong to lose compile-time
type checking save under grave environmental stress, the likes
Why are you losing checking? It would seem right now keys
would first check to make sure it'll be getting *something* OR die
then to make sure that that something is a hash OR die
And all I said was replace the last OR die with:
OR warn (if under strict|-w) AND cast at run-time
If you gave it hash you short-circuit right out and have not lost any time.
If it in fact is not a hash, you may get warning under strict or -w.
of which you are yet to demonstrate. The burden of proof rests
with you to show why to turn perl dumber.
This is *not* making it dumber, the only way it would make it dumber is if
you lost your test. But you don't have to lose your compile-time test...
But that comes with similar attendant problems. What then
should
while ( ($k,$v) = each fn() ) {}
do? How often should fn() be called there? And what if it
returns a hash ref versus a list? What about a list of one
hash ref?
It should be called once, otherwise you would loop indefinitely.
It should then pass every other value into $k and $v, while you iterate
over the contents. For example:
while ( ($k,$v) = each fn() ){
push @F, $k;
push @G, $v;
}
not being dissimilar from
@F = fn();
unzip(2, \@F)
Comflating values with variables is not always sensible: consider
4++, for example; this isn't (old) FORTRAN. :-)
Well that's a different issue, since that always evaluates to the same thing...
--
* __* .
\ | / .. . . . ((_
_ . . .
-- / \ -- .. . +. . _/\
oo. | * . . . * / ;M\_ .
..oo. . .. . /\. / :IMM\
....oo. Jerrad Pierce /\ / \ / ;IIWMM
..oo... 209 North Street +/ \ / \ . / ;WM
...o... Randolph, MA 02368/ \ \ ___/ :;IWM
oooo.../\\ / :: ;;IIIMI
.ooo.http://www.pthbb.org /\ \ : :::;IIIM
..ooo __ || || ::.::
MOTD on Prickle-Prickle, the 15th of Bureaucracy, in the YOLD 3166:
"God is too big for only one religion." -- A. Weysman
Re: functions that deal with hash should be more libera
John Porter writes:
I suppose that's true. But why would
%( foo = 1, bar = 2 )
be "working harder" than
%{{ foo = 1, bar = 2 }}
??? It's few keystrokes and would be a less tricky concept
to remember.
It's a new syntax, not orthogonal to anything we already have. The
number of people wanting to coopt %{ or %( or %[ is truly frightening.
I think the message is: Don't put time into the parser when your
effort could better be spent in the optimizer.
Nat
Re: functions that deal with hash should be more liberal
I assure you that the number of people who get compile-time caught for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is *very* large. This is by far the most prevalent error that happens with data structures in apprentice and perhaps even journeymen perl programmers. Having the compiler immediately report this at run time is very important, and not at all worth losing. Go teach thousands of people perl data structures, and then you'll see what I mean. --tom
Re: functions that deal with hash should be more libera
Nathan Torkington wrote:
John Porter writes:
I suppose that's true. But why would
%( foo = 1, bar = 2 )
be "working harder" than
%{{ foo = 1, bar = 2 }}
??? It's few keystrokes and would be a less tricky concept
to remember.
It's a new syntax, not orthogonal to anything we already have.
So? Perl's not like that. Perl is diagonal. And this is just
another corner being cut.
I have a list of stuff that looks a lot like a hash:
( foo = 1, bar = 2 )
Now, gol dern it, I want to treat it like a hash. I want *perl*
to let me treat it like a hash. Directly!
If not
keys ( foo = 1, bar = 2 )
then
keys %( foo = 1, bar = 2 )
Or *something*.
I think the message is: Don't put time into the parser when your
effort could better be spent in the optimizer.
Who "you"? This is the -language list.
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
John Porter writes:
So? Perl's not like that. Perl is diagonal. And this is just
another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the existing syntax. I have a document
coming on this to try and point people who want to give meaning to
every possible combination of punctuation and alphanumerics in the
right direction.
Perl is already very hairy and full of punctuational quirks. I think
we need a fairly compelling argument.
I have a list of stuff that looks a lot like a hash:
( foo = 1, bar = 2 )
Now, gol dern it, I want to treat it like a hash. I want *perl*
to let me treat it like a hash. Directly!
A hash is a specific data structure, currently encapsulated in the
innards as an HV. What you have is a list. You can assign that list
to a hash, in which case Perl builds an HV for you.
If not
keys ( foo = 1, bar = 2 )
then
keys %( foo = 1, bar = 2 )
I personally prefer:
('foo', 'bar')
or even
qw(foo bar)
for that.
Seriously, how many times do you want to call keys or values on
a list and then never do anything else with it? Very very rarely.
Most of the times you say:
foreach $foo (keys %bar) {
# do something with $foo and $bar
}
or at the very least you save away the list of keys and do something
with the corresponding values later on.
Yes, there are a few situations (e.g, where the presence of the key in
the hash is important not the actual value stored with the key) where
you might want the keys returned by a function but nothign else.
But those are mighty mighty rare.
In those mighty rare cases, I say you should have to deal with:
keys %{{ foo() }}
Nat
Re: functions that deal with hash should be more libera
Today around 3:01pm, John Porter hammered out this masterpiece:
: Nathan Torkington wrote:
: John Porter writes:
: I suppose that's true. But why would
: %( foo = 1, bar = 2 )
: be "working harder" than
: %{{ foo = 1, bar = 2 }}
: ??? It's few keystrokes and would be a less tricky concept
: to remember.
:
: It's a new syntax, not orthogonal to anything we already have.
:
: So? Perl's not like that. Perl is diagonal. And this is just
: another corner being cut.
As a user, I should be able to expect this:
sub func {
return ( qw/KeyOne Value1 KeyTwo Value2/ );
}
my %hash = func();
print "$_\n" foreach keys %hash;
To work just like this:
print "$_\n" foreach keys func();
In my, 'pretending to just learn' mode, I don't understand. Perl will assign
the LIST to the hash in example one, but in example two, it croaks.
Removing intermediate data structures is easy in Perl, but not this case,
instead, I have to do this:
%{{func()}};
How... not easy to learn.
Especially since it's not documented. Perhaps, at least for the current version
of Perl, this should be documented in perlfunc under keys(), values() and
each(). Also in perlfaq4, although I bet this is not a frequent question.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: functions that deal with hash should be more libera
my %hash = func();
print "$_\n" foreach keys %hash;
To work just like this:
print "$_\n" foreach keys func();
In my, 'pretending to just learn' mode, I don't understand. Perl will assign
the LIST to the hash in example one, but in example two, it croaks.
A LIST is not a HASH. Learn that. Be done with it. Move on.
Removing intermediate data structures is easy in Perl, but not this case,
instead, I have to do this:
%{{func()}};
How... not easy to learn.
Especially since it's not documented. Perhaps, at least for the currentSNIP
Say what?
--tom
Re: ... as a term
I think this is fraught with peril. I'd have expected: print (1, 2, 3, ...) or die; to print 12345678910111213141516171819202122232425262728etc No, if that's what you wanted, you'd get it with print( 1, 2, 3 .. ) # RFC 24 Sure, but I said "expected", not "wanted". I was pointing out that the distinction between the two syntaxes is too subtle, especially since, in English, we write infinite lists with three dots, not two. Damian
Re: functions that deal with hash should be more libera
As a user, I should be able to expect this: I've decided I don't believe you, because despite having taught a zillion people Perl, I have never *once* seen the misexpectation and subsequent error that you're spending so much time complaining about. --tom
Re: functions that deal with hash should be more libera
Today around 1:41pm, Tom Christiansen hammered out this masterpiece:
: my %hash = func();
: print "$_\n" foreach keys %hash;
:
: To work just like this:
:
: print "$_\n" foreach keys func();
:
: In my, 'pretending to just learn' mode, I don't understand. Perl will assign
: the LIST to the hash in example one, but in example two, it croaks.
:
: A LIST is not a HASH. Learn that. Be done with it. Move on.
Goodness man, I got it, I have gotten it. Perhaps I'm using wrong terminology,
but I understand.
: Removing intermediate data structures is easy in Perl, but not this case,
: instead, I have to do this:
:
: %{{func()}};
:
: How... not easy to learn.
:
: Especially since it's not documented. Perhaps, at least for the currentSNIP
:
: Say what?
Well, there is a mention to the effect of:
@uniq = keys %{{%foo,%baz}};
in perlfaq4.
And perlfunc says that keys only works on 'named hashes'. I suppose to a
seasoned veteran, that's sufficient.
There is no documentation that states:
``keys() just doesn't work on lists and/or arrays, you must use this syntax to
force that to work:
@array = keys %{{@array}};
''
Or something like that.
This suggestion was brought up as a means to make these functions more user
friendly.
If it's impossible, then I'll be glad to forget about it.
[Insert many replies that agree here, I'm sure.]
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: functions that deal with hash should be more libera
Today around 1:51pm, Tom Christiansen hammered out this masterpiece:
: As a user, I should be able to expect this:
:
: I've decided I don't believe you, because despite having taught a
: zillion people Perl,
Commendable. I value your expertise.
: I have never *once* seen the misexpectation and subsequent error that you're
: spending so much time complaining about.
Perhaps you never taught me :-)
Perhaps if you had, I wouln't be having this problem.
Perhaps, since you are ( or have been ) so prominent in documenting Perl, you
could and/or would help other people like me to understand this
problem/bug/feature/not too noticed 'thing'.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: functions that deal with hash should be more libera
There is no documentation that states:
``keys() just doesn't work on lists and/or arrays, you must use this syntax to
force that to work:
@array = keys %{{@array}};
''
Or something like that.
keys is documented to take a hash. Likewise, push an array.
This all seems completely obvious.
--tom
Re: functions that deal with hash should be more libera
Casey R. Tweten wrote:
Removing intermediate data structures is easy in Perl, but not this case,
Ceach, etc. must have data structures to work on. There's no "getting rid"
of them.
"I want find /usr to search the directory tree, but, um, I don't want to
actually *have* a directory tree..."
Especially since it's not documented.
Oh, it is. The documentation of Ceach, Ckeys, and Cvalues all state
clearly that they operate on HASH variables. And perldata and perlref
clearly describe how to make a HASH variable on the fly.
{ foo = bar } # create a HASH, getting a ref to it.
%{ ... } # dereference a HASH ref
--
John Porter
We're building the house of the future together.
Re: functions that deal with hash should be more libera
Casey R. Tweten wrote: There is no documentation that states: ``keys() just doesn't work on lists and/or arrays, Why should it bother saying that, when it already says keys() works on a HASH? Or is there some confusion that a HASH might also be an ARRAY or a LIST? -- John Porter We're building the house of the future together.
Re: functions that deal with hash should be more libera
[to you only, as this thread is now distinctly off-topic for perl6-language]
Buddha Buck wrote:
@array1 = (1, 1, 3, 5, 8, 13);
%hash1 = ('foo', 34, 'bar', "not a number", 'baz', 4);
@array2 = %hash1;
%hash2 = @array1;
This works, and may lead to confusion because:
This is exactly what I was referring to in an earlier post --
that the well-definedness of these assignment operations leads
the unsuspecting to believe that there really is some kind of
equivalence of the underlying structures, when in fact there
is not.
Reading that, what would you say the difference between an array, a list,
and a hash is?
(My answer: From that glossary, I'd say that 'array' and 'list' are
virtually synonymous. From actual use, I'd say that an array can be an
lvalue, but a list is strictly an rvalue.)
( $a, $b, $c ) = ( 1..100 );
No, lists can be lvalues too.
The difference, as stated before, is that LISTs are not variables; that
is, a list has no unified internal data structure, upon which such
operations as push() or each() might work. Some people like to say that
a list is just a bunch of scalar values on the stack; but if you don't
think in terms of call stacks, that analogy doesn't illuminate.
I like to think of variables (scalars, arrays, and hashes) as being
Perl's intrinsic object types; each supports a set of methods: array
supports the push() method, hash supports the each() method, etc.
Thinking of it in these object-oriented terms, I can say that a LIST
is not an object, and so does not support any object methods.
There are some things you *can* do with a list, such as index into it
to get specific elements; but this is merely a syntactic convenience
for the programmer, and has little to do with indexing into a true
array variable.
Hope this helps,
--
John Porter
Re: functions that deal with hash should be more libera
It doesn't help that Camel II's glossary defines "array" as "A named list of values, each of which has a unique key to identify it. In a normal array, the key is numeric... In a hash...the key is a string." and seems to go to a lot of effort to deprecate "array" in favor of "list" (array context: "A quaint, archaic expression used by people who have read the first edition of this book. Nowadays called 'list context'."). Here's from Camel III. I hope you find this more helpful than before. =item Barray An ordered sequence of values, stored such that you can easily access any of the values using an integer subscript that specifies the value's offset in the sequence. =item Barray context An archaic expression for what is more correctly referred to as Ilist context =item Bhash An unordered association of Ikey/Ivalue pairs, stored such that you can easily use a string Ikey to look up its associated data value. This glossary is like a hash, where the word to be defined is the key, and the definition is the value. A hash is also sometimes septisyllabically called an "associative array", which is a pretty good reason for simply calling it a "hash" instead. =item Bhash table A data structure used internally by Perl for implementing associative arrays (hashes) efficiently. See also Ibucket. =item BLIST A syntactic construct representing a comma-separated list of expressions, evaluated to produce a Ilist value. Each Iexpression in a RLIST is evaluated in a Ilist context and interpolated into the list value. =item Blist An ordered set of scalar values, =item Blist context The situation in which an Iexpression is expected by its surroundings (the code calling it) to return a list of values rather than a single value. Functions that want a RLIST of arguments tell those arguments that they should produce a list value. See also Icontext. Reading that, what would you say the difference between an array, a list, and a hash is? I'm not sure from reading that. The answer that comes to my mind is that an array has an AV (updatable array metadata header structure) and a hash an HV (similarly), but a list--well, that's just SVs sitting around on a stack somewher. But that's not very useful for anyone who's still confused. (My answer: From that glossary, I'd say that 'array' and 'list' are virtually synonymous. From actual use, I'd say that an array can be an lvalue, but a list is strictly an rvalue.) Actually, you *can* use a list lvalueably, provided that each of that list's components is also a legal lvalue. For example: ($a, $b, $c, $d, @etc) = fn(); However, currently you can't switch those, even for lvaluable functions. --tom
Re: RFC 133 (v1) Alternate Syntax for variable names
Consider the following syntax:
my var; # declaring a scalar
my array[]; # declaring an array
my hash{};# declaring a hash
For the remainder of the enclosing block, the barewords var,
array and hash are to be interpreted as references to a scalar, an
array, and a hash.
As long as assignment starts doing automatic dereferencing this
will not be too tricky, it will require adding some work to Cmy
and adding more barewords to the local bareword board.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE One Should Not Get Away With Ignoring System Call Errors =head1 VERSION Maintainer: Jarkko Hietaniemi [EMAIL PROTECTED] Date: 22 August 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 140 =head1 ABSTRACT =head1 EXECUTIVE SUMMARY If something fails, you should care. =head1 TERMINOLOGY In the following 'system calls' mean anything not in the core language calling an external service, be it a 'real' system call (such as accept(), fork(), mkdir()) or a 'library' call (such as print(), syswrite() getpwent()). The difference is often arbitrary and depends on the implementation details of the operating system and the libraries. This difference is irrelevant for the purposes of this RFC (though relevant for the low-level implementation of this proposal). =head1 DESCRIPTION The 'strict' pragma (or whatever form it takes in perl6) should include in its 'default set of strictness' a new subpragma, 'system'. This subpragma has the following semantics: =over 4 =item * For many system calls it is possible to say during Bcompile time that ignoring their return value is foolish and should be punished (by aborting during compilation). Examples of such system calls: open(), mkdir(), chdir(). There simply isn't an excuse for ignoring their return values. =item * For other system calls aborting during compile time may be too harsh: print() is an obvious example. But print() can fail, too: out of disk space, out of quota, closed socket. Such softer failures are indicated (at C level) by e.g. return of -1 and/or turning on errno. Such failures are detectable during Bruntime, and if, running under 'use strict', should croak. Lexical warnings could warn about such system calls: "print() can fail during runtime". =back =head2 Cheating Is Still Possible Not ignoring the return value is of course no guarantee of doing anything useful with the return value: $so_what++ unless defined fork(); But detecting whether 'something useful' is done is squarely in the realm of heavy AI. =head2 Is That An Object In Your Pocket Or Are You Just Oriented To See Me? This proposal does not deal with any object oriented issues, whether the detected errors 'throw' any 'exceptions' and how the user can 'catch' them. The proposed strict handling of system call failures should be independent of any higher level concepts such as object oriented 'exception handling'. Exception handling is welcome to provide ways to muster these low-level error conditions, though. =head1 MIGRATION ISSUES By having this new level of bondage-and-discpiline tucked away under 'use strict' the quick hack one liner nature of Perl is still available. =head1 REFERENCES perl6-language-errors perl6-language-strict perl6-language-io
