Re: Divide by 0? Was: Re: Introduction Letter
On Tue, Mar 01, 2005 at 08:13:46AM +, Fergal Daly wrote: On Mon, Feb 28, 2005 at 07:55:36PM -0600, Eric Wilhelm wrote: I like the one where you get the mathematically-correct (or at least mathematically-useful) infinity. $perl -le 'use bigint; $x = 1/0; print $x+1' inf $perl -le 'use bigint; $x = 1/0; print 1/$x' 0 and what should these print? $perl -le 'use bigint; $x = 2/0; print $x*0' $perl -le 'use bigint; $x = 1/0; print ($x+1)-$x' $perl -le 'use bigint; $x = 1/0; print ($x*2)/$x' I don't know, but I do know that having the interpreter crap out is not helpful to most of us simpletons who find phrases like core dumped not especially user friendly. Maybe if there is a divide by zero you could set one of the cussword variables ([EMAIL PROTECTED]@#$!) in addition to returning undef or inf, whatever. Then if you mathematically correct types don't like the result you can make your own, or go back to crapping out by kill(SIGBUS,$$). I suppose I could try to create a use divide 0/undef/inf/crap pragma. Then you could do whatever you want. You'd still get a surprise if you ever forgot it though.. Austin
Re: Divide by 0? Was: Re: Introduction Letter
Austin Schutz wrote: I suppose I could try to create a use divide 0/undef/inf/crap pragma. Then you could do whatever you want. You'd still get a surprise if you ever forgot it though.. I think that's the best answer. Not a good idea for most programs, wonderful idea for math programs - which can simply say use infinity; or something along those lines at the top. BTW-I'm reading Perl 6 Now, and I believe there was mention there about Perl 6 having support for infinity and possibly other equally strange notions. I'm at work, though, so I don't have access to the book right now. -ofer
Re: Introduction Letter
On Sun, 2005-02-27 at 16:28 -0800, Ofer Nave wrote: 2) requesting feedback on design/implementation For reviews there's also the code-review-ladder: http://lists.netthink.co.uk/listinfo/code-review-ladder -- Bye, -Torsten
Re: Introduction Letter
Andrew Savige wrote:
[...]
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
until I noticed HTML::Parser uses this style. Alternatives are
I like this style.
CamelCase style (a la XML::Parser, for example):
{ UseReturn = 1 },
I think this is yucky. Its use is eschewed for variable names (perlstyle
says that it's harder for non-native English speakers) so I don't see
that it has any legitimate use for hash keys (which are nothing more
than second-class variable names).
or dash-option style (a la CGI, for example):
{ -use_return = 1 },
I'm not too fond of this either. I've always felt that it's trying to
emulate command line switches, poorly. It fails on multi word names. A
longword switch should be written as --use-return, at least according to
long-standing tradition. It grates on my nerves when I see switches that
mix dashes and underscores like --use_return. That just feels wrong, as
if the author isn't aware of prior art.
And so if you accept my hypotheses that --use-return is the Right Thing,
then you can't specify that as a hash key bareword. Hence I judge it to
be a failure.
So I would tend to consider that { use_return = 1 } is the preferred
way. I certainly find it to be the most appealing from a visual point of
view.
I'm damned if I can find a reference clearly stating which one of
these three styles is preferred. Can anyone point me to a reference
on this?
Nor can I, but my gut feeling is that most of the modules I use on a
regular basis use the first form.
David
Re: Introduction Letter
* Andrew Savige [EMAIL PROTECTED] [2005-02-28T04:22:04]
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { prun }
...which, in turn, is better implemented as
sub run { goto prun }
because it will never have to return to run. The return value of prun
will be returned directly.
Or, finally:
*run = \prun
which will just make calls to run invoke prun directly.
--
rjbs
pgp66ooVqWZSK.pgp
Description: PGP signature
Re: Introduction Letter
* Andrew Savige [EMAIL PROTECTED] [2005-02-28 10:25]:
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought
not until I noticed HTML::Parser uses this style.
File::Find also uses this. So do a large number of OO modules
which use named parameters. This style follows accepted naming
practice for variables and subs/methods.
Alternatives are CamelCase style (a la XML::Parser, for
example):
Yuck. We look down on that in variable and sub/method names; why
would we prefer it for hash keys?
or dash-option style (a la CGI, for example):
Ech! This meme should be killed with great prejudice. It makes
code noisy for no good reason. Try reading the source of a
complex Tk GUI and tell me if you don't think it looks ugly and
messy. Four thumbs down to this idea.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
RE: Introduction Letter
Title: RE: Introduction Letter messy. Four thumbs down to this idea. You have four thumbs Aristotle? Must make for a crowded space bar eh? ;-) Yves
Re: Introduction Letter
On Mon, 28 Feb 2005, Torsten Schoenfeld wrote: http://lists.netthink.co.uk/listinfo/code-review-ladder That box was having hardware problems last week. The maypole lists were on the box (now they're on SrcFrg), so maybe this has moved somewhere else too. -- /chris There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author)
Re: Introduction Letter
* Orton, Yves [EMAIL PROTECTED] [2005-02-28 14:45]: messy. Four thumbs down to this idea. You have four thumbs Aristotle? Must make for a crowded space bar eh? Heh, got me. I was referring to thumbs + big toes, wrongly assuming the toes are called thumbs in English. I actually had to rummage around in my memory when it occured to me that they're not called the same as thumbs in German either. It is becuase there are no separate words for toes or thumbs in Greek. The thumb is just the big finger, and the toes are fingers of the foot, and the big toe is referred to as big finger of the foot. So basically, four big fingers down to the idea. Okay, that was very offtopic. Regards, -- Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: Introduction Letter
On Mon, 28 Feb 2005, Andrew Savige wrote:
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
This is pretty common. Pretty much every module I've written uses it ;)
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Introduction Letter
Andrew Savige wrote:
--- Ofer Nave wrote:
Here's the POD for my new Parallel::Simple module:
Interface
-
To me, offering both:
Parallel::Simple::run()
and:
Parallel::Simple-run()
just makes the interface bigger -- more for the user to read and
grok -- without any benefit (at least, none I can see). Suggest
you drop the second form (which does not currently work correctly
because the class name is passed as the first parameter and is not
being shifted). Ditto for offering the run() synonym for prun().
I realized last night that it's impossible for me to support both
syntaxes with anything better than a total hack, so I'm throwing it
out. In fact, I've replaced all occurances of the word 'method' with
'function'. It's no an OO module, it doesn't need method calling
syntax. I just tried to put it in initially because 'class methods'
seem all the rage now, and I thought I'd just follow the example of
those I respect.
I've also now removed any traces of the run() synonym. You're right -
why complicate things with no benefit.
Naming. I wonder if your:
{ use_return = 1 },
is the recommended Perl style for named parameters? I thought not
until I noticed HTML::Parser uses this style. Alternatives are
CamelCase style (a la XML::Parser, for example):
{ UseReturn = 1 },
or dash-option style (a la CGI, for example):
{ -use_return = 1 },
I'm damned if I can find a reference clearly stating which one of
these three styles is preferred. Can anyone point me to a reference
on this?
I've seen all three. They're all good, so I'm up for using any one of
them. I chose all-lowercase initially to match the identifer naming
conventions.
Your example:
die( Parallel::errplus );
should be written:
die( Parallel::errplus() );
to avoid bareword error under use strict.
Again, I copied that convention from the greats - in this case,
DBI::errstr. In the examples, Tim never includes the parentheses.
What's funny is that I actually like the parentheses, since I strive to
avoid any ambiguity, but I left them off here because I was trying to
make my first CPAN module as perl-ish as possible - when in Rome and all
that. I'll add parentheses back on.
Incidentaly, the above should have read die( Parallel::Simple::errplus
);. I left out the 'Simple::'. Amazing where you find bugs nowadays. :)
Implementation
--
Just a couple of micro-optimizations I noticed.
This function synonym:
sub run { prun( @_ ) }
is better implemented as:
sub run { prun }
This special form of sub call makes current @_ visible to called
subroutine. I suppose the primitive-obsessed might prefer:
*Parallel::Simple::run = \prun;
After sending my email out, I discovered that realpath() is an alias in
the Cwd module and hit the source to see how it's being done. They're
using the function aliasing style, which I believe is the fastest (
*alias = \function ), so I changed my code to that style. Of course,
five minutes ago I got rid of the alias entirely (per your suggestion),
so this is no longer relevant.
In a couple of places, I noticed:
/HASH/o
The /o modifier is meaningless here and should be removed.
Ok.
You get the return code here:
$child_registry{$child}[1] = $? 8;
yet miss getting if it died hard from a signal via:
$? 127;
Further getting whether it dumped core via:
$? 128;
is probably overkill. Not sure how this would affect your interface,
but I've seen cases where a process crashes yet returns a $? 8
of zero while $? 127 is 11 (SIGSEGV).
Seriously? Is there anywhere I can learn more about this?
-ofer
Re: Introduction Letter
Ofer, With all due respect to Andrew, please remember that his is but one opinion. I've also now removed any traces of the run() synonym. You're right - why complicate things with no benefit. I didn't see anything wrong with the concept. Personally I would have done it the other way around (i.e. make prun a synonym for Parallel::Simple::run), but that's a minor point. To me, run is a perfectly reasonable name for the function when fully qualified, but it makes sense not to export (even only when requested) such a simple function name into the global namespace. In fact, I might go even further and name it par_run or somesuch. But that's just me. Oh, and I do agree with the comments about using *Parallel::Simple::run = \prun; instead of the way you've done it. That's the proper way to create a synonym IMHO. What's funny is that I actually like the parentheses, since I strive to avoid any ambiguity, but I left them off here because I was trying to make my first CPAN module as perl-ish as possible - when in Rome and all that. I'll add parentheses back on. Using the without parends style is perfectly valid. It won't cause a bareword error unless the subroutine is undefined. Many people prefer it. I personally use both ... I know that would drive many people crazy as inconsistent, but I actually feel that sometimes it seems more natural with and sometimes without. Bottom line is go with whichever you personally prefer. Seriously? Is there anywhere I can learn more about this? Try perlfunc system just for a start. -- Buddy
Re: Introduction Letter
Buddy Burden wrote: Ofer, With all due respect to Andrew, please remember that his is but one opinion. I've also now removed any traces of the run() synonym. You're right - why complicate things with no benefit. I didn't see anything wrong with the concept. Personally I would have done it the other way around (i.e. make prun a synonym for Parallel::Simple::run), but that's a minor point. To me, run is a perfectly reasonable name for the function when fully qualified, but it makes sense not to export (even only when requested) such a simple function name into the global namespace. In fact, I might go even further and name it par_run or somesuch. But that's just me. True, but my own thoughts were already somewhat in tune with Andrew's suggestion. Having two names was cluttering the docs, with the only benefit being the lack of the redundant 'p' on fully-qualified calls. Oh, and I do agree with the comments about using *Parallel::Simple::run = \prun; instead of the way you've done it. That's the proper way to create a synonym IMHO. What's funny is that I actually like the parentheses, since I strive to avoid any ambiguity, but I left them off here because I was trying to make my first CPAN module as perl-ish as possible - when in Rome and all that. I'll add parentheses back on. Using the without parends style is perfectly valid. It won't cause a bareword error unless the subroutine is undefined. Many people prefer it. I personally use both ... I know that would drive many people crazy as inconsistent, but I actually feel that sometimes it seems more natural with and sometimes without. Bottom line is go with whichever you personally prefer. Personally, I almost always prefer parens on function calls. For built-ins, my philosophy is more complicated, and I won't go into it here. :) I've added them for the docs, since the point of docs is to make things as clear as possible. Users can always do their own thing, as usual. :) Seriously? Is there anywhere I can learn more about this? Try perlfunc system just for a start. No, I'm familiar with the make-up of the 16-bit return value of the system call. What I want to learn more about is the possibility that a process could crash and yet return a 0 exit code. I had not thought that possible, and hence, had seen no need to test for $? 127. -ofer
better SEE ALSO sections (was: Re: Introduction Letter)
On Mon, Feb 28, 2005 at 08:57:04AM -0500, Christopher Hicks wrote: This is a phenomenal initial cut of a POD. The review of relevant other modules in SEE ALSO and the philisophical differences with each deserves particular note. Bravo. I share your appreciation. I agree that this part of the documentation is frequently sub-optimal from a users perspective, especially when a new alternative appears when they are several standard options. For example (and not to pick on a particular module), here's one that was just released today: http://search.cpan.org/~jbuhacoff/Data-SimplePaginator-0.1/lib/Data/SimplePaginator.pm I was hoping for more of a comparison with Data::Page, which is similar but already established. Mark
Re: better SEE ALSO sections (was: Re: Introduction Letter)
On Mon, Feb 28, 2005 at 04:05:09PM -0500, Mark Stosberg ([EMAIL PROTECTED]) wrote: I was hoping for more of a comparison with Data::Page, which is similar but already established. AND at 100% Devel::Cover coverage, thanks to yours truly! :-) xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Introduction Letter
* Buddy Burden [EMAIL PROTECTED] [2005-02-28 19:20]:
I've also now removed any traces of the run() synonym. You're
right - why complicate things with no benefit.
I didn't see anything wrong with the concept. Personally I
would have done it the other way around (i.e. make prun a
synonym for Parallel::Simple::run), but that's a minor point.
Personally, I would pick yet another different approach: call the
function run, but export it as prun. When qualified with
Parallel::Simple::, even the very short run identifier is clear
and unambiguous. When exported, however, a simple run is more
likely to clash than prun and might be harder to search the
source for too.
Oh, and I do agree with the comments about using
*Parallel::Simple::run = \prun;
Note that this is how exporting works -- the only difference is
that the left and right hand side of the assignment refer to
symbols in different packages. So there's a sort of natural
precedent for my preference of exporting with a longer name...
Try
perlfunc system
just for a start.
Surely you mean
perldoc -f system
? :)
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Divide by 0? Was: Re: Introduction Letter
On Tue, Mar 01, 2005 at 11:43:31AM +1100, Andrew Savige wrote:
running this Perl program:
use strict;
sub div_by_zero { exec(./a.out $_[0]); die should not be here }
defined(my $pid = fork()) or die fork: $!;
if ($pid == 0) {
warn child, my pid $$\n;
div_by_zero(0); # sig 8
# div_by_zero(); # sig 11
exit;
}
warn parent, my pid $$\n;
waitpid($pid, 0);
my $rv = $? 8;
my $sig = $? 127;
warn $$: rv=$rv sig=$sig\n;
produces:
parent, my pid 12091
child, my pid 12092
12091: rv=0 sig=8
Replacing div_by_zero() above with:
sub div_by_zero { 5 / shift }
produced:
parent, my pid 12133
child, my pid 12134
Illegal division by zero at g2.pl line 2.
12133: rv=255 sig=0
This is not related to the original topic, but I've always
wondered this: In math a number divided by 0 is undefined. Why is it
that in a language which has an undefined value does the interpreter
poop out rather than just having the intuitively obvious behavior of
returning undef? Is that really by design, or just a legacy quirk they're
afraid to fix?
Austin
Re: Divide by 0? Was: Re: Introduction Letter
Austin Schutz wrote: This is not related to the original topic, but I've always wondered this: In math a number divided by 0 is undefined. Why is it that in a language which has an undefined value does the interpreter poop out rather than just having the intuitively obvious behavior of returning undef? Is that really by design, or just a legacy quirk they're afraid to fix? Austin Which would you prefer? $ perl -le '$x=1/0; print $x+1' Illegal division by zero at -e line 1. or $ perl -le '$x=1/0; print $x+1' 1 It only makes sense if undef in any arithmetic operation always gives undef, which means that all variables have to be explicitly initialized to zero before you can perform any arithmetic on them. That breaks tons of useful idioms and generally adds programming overhead. You shouldn't confuse undefined meaning not definable (math) with not yet defined (Perl). David
Re: Divide by 0? Was: Re: Introduction Letter
# The following was supposedly scribed by # David Golden # on Monday 28 February 2005 07:07 pm: Which would you prefer? $ perl -le '$x=1/0; print $x+1' Illegal division by zero at -e line 1. or $ perl -le '$x=1/0; print $x+1' 1 I like the one where you get the mathematically-correct (or at least mathematically-useful) infinity. $perl -le 'use bigint; $x = 1/0; print $x+1' inf $perl -le 'use bigint; $x = 1/0; print 1/$x' 0 --Eric -- Everything should be made as simple as possible, but no simpler. -- Albert Einstein - http://scratchcomputing.com -
