[32625] in Perl-Users-Digest
Perl-Users Digest, Issue: 3900 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 14 00:09:24 2013
Date: Wed, 13 Mar 2013 21:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 13 Mar 2013 Volume: 11 Number: 3900
Today's topics:
bytes, English, and prototypes <oneingray@gmail.com>
Re: bytes, English, and prototypes <rweikusat@mssgmbh.com>
Re: bytes, English, and prototypes <ben@morrow.me.uk>
Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) <ben@morrow.me.uk>
Re: message forwarding in perl <ben@morrow.me.uk>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <rweikusat@mssgmbh.com>
Re: message forwarding in perl <ben@morrow.me.uk>
prototypes? <oneingray@gmail.com>
Re: prototypes? <rweikusat@mssgmbh.com>
Re: prototypes? <rweikusat@mssgmbh.com>
Re: prototypes? <ben@morrow.me.uk>
Re: prototypes? <rweikusat@mssgmbh.com>
Re: prototypes? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 13 Mar 2013 17:28:00 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: bytes, English, and prototypes
Message-Id: <87y5drky5b.fsf_-_@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[Dropping news:comp.lang.perl.modules and news:alt.barcodes from
Followup-To:.]
[...]
>> $ cat < 89br96tnpoogun68sfh1jkj1sb.perl
>> use bytes;
> You should not use 'bytes'. It doesn't ever do anything useful and
> sometimes lets you look at parts of the perl internals you shouldn't
> be looking at.
Indeed, I've read the documentation. It was my understanding
that, in the nutshell, the "bytes" pragma makes Perl operate
strictly on octet sequences for its strings, instead of allowing
either strings of octets /or/ strings of Unicode characters.
Frankly, I do not see any harm in using this pragma /provided/
that the code doesn't switch it on and off at will.
The question on what setting do the loaded modules use remains
open, but for the specific example I've given (which uses no
text-processing modules) I'd expect the chances of running into
issues to be quite low.
[...]
>> use English;
> You should not use English, it makes your code harder to read for
> anyone who knows Perl, and teaches you bad habits.
? I may be having a bit too much Lisp background, but I've
always considered something_that_one_can_read to be a way better
identifier for a global than, say, ~.
Besides, there's a chance that the code I write will be read by
someone not quite knowing Perl.
[...]
>> sub rand_blob (;$) {
> You should not use prototypes unless you need the special parsing
> effects they cause.
Is there a practical reason to forgo the compile-time arguments'
type checking they offer? For me, code that fails to compile is
better than code that suddenly dies after running for hours.
(Which is still better than the code that dies at the wrong
place; or doesn't die, but silently gives a wrong result.)
[...]
> Unless you need cryptographic randomness (and since you're using
> urandom, you don't), it would be better to use something like
> sub rand_blob {
> my ($len) = @_;
> $len //= 24;
> return join "", map chr rand 0xff, 0..$len;
> }
ACK, thanks. (Although, my guess is that even if urandom(4) is
worse than random(4), Perl's rand is worse, randomness-wise,
still.)
--
FSF associate member #7257
------------------------------
Date: Wed, 13 Mar 2013 17:54:26 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: bytes, English, and prototypes
Message-Id: <87y5dri3sd.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
[...]
>>> sub rand_blob (;$) {
>
>> You should not use prototypes unless you need the special parsing
>> effects they cause.
>
> Is there a practical reason to forgo the compile-time arguments'
> type checking they offer? For me, code that fails to compile is
> better than code that suddenly dies after running for hours.
Prototypes are really only useful for 'compile-time argument checking'
in code which circumvents the 'individual' ways Perl operators deal
with their arguments by always putting them in brackets. Otherwise,
you'll be adding similar 'individual ways to deal with arguments' to your
subroutines as a (probably undesired) side effect and this might
confuse people who expect all subroutines to behave identical when not
bracketing the arguments.
NB: I'm using prototypes for compile-time checking as well but usually
remove them from any code I post here.
------------------------------
Date: Wed, 13 Mar 2013 23:00:43 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bytes, English, and prototypes
Message-Id: <r1d71a-pik1.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> $ cat < 89br96tnpoogun68sfh1jkj1sb.perl
>
> >> use bytes;
>
> > You should not use 'bytes'. It doesn't ever do anything useful and
> > sometimes lets you look at parts of the perl internals you shouldn't
> > be looking at.
>
> Indeed, I've read the documentation. It was my understanding
> that, in the nutshell, the "bytes" pragma makes Perl operate
> strictly on octet sequences for its strings, instead of allowing
> either strings of octets /or/ strings of Unicode characters.
That was the original idea, in the 5.6 days, but it never worked like
that in practice because it turns out to be basically impossible to
prevent character strings from leaking in to your 'use bytes' sections.
If you don't want strings containing characters above 0xff, don't create
them. 'bytes' doesn't gain you anything in that case.
> Frankly, I do not see any harm in using this pragma /provided/
> that the code doesn't switch it on and off at will.
>
> The question on what setting do the loaded modules use remains
> open, but for the specific example I've given (which uses no
> text-processing modules) I'd expect the chances of running into
> issues to be quite low.
This is exactly the problem.
> >> use English;
>
> > You should not use English, it makes your code harder to read for
> > anyone who knows Perl, and teaches you bad habits.
>
> ? I may be having a bit too much Lisp background, but I've
> always considered something_that_one_can_read to be a way better
> identifier for a global than, say, ~.
That can be argued both ways (the magic punctuation variables stand out
more, by virtue of being different, than any alphanumeric name) but
either way it doesn't really matter: what matters is that consistency is
more important than correctness when it comes to spelling, and in Perl
errno is spelled $!.
> Besides, there's a chance that the code I write will be read by
> someone not quite knowing Perl.
Then you will be teaching them bad habits, as well as yourself. These
habits are not inherently bad: had 'English' been the default from the
start we might in some sense be better off. They are only bad because
they make your code unintelligible to others, and others' code to you.
> >> sub rand_blob (;$) {
>
> > You should not use prototypes unless you need the special parsing
> > effects they cause.
>
> Is there a practical reason to forgo the compile-time arguments'
> type checking they offer?
They do more than that: they change the context of the parameters to the
call, which is (usually) entirely unexpected:
sub foo (;$$) {
say $_[0], $_[1];
}
my @x = ("a", "b");
foo(@x);
The exception to this is for functions which are intended to imitate
builtins (which is what prototypes were originally for), so prototypes
like ($), (&@), (\@@) can be useful, when used appropriately.
> For me, code that fails to compile is
> better than code that suddenly dies after running for hours.
> (Which is still better than the code that dies at the wrong
> place; or doesn't die, but silently gives a wrong result.)
I agree, actually, and a general form of compile-time argument checking
would be nice; but Perl 5 prototypes aren't it.
Ben
------------------------------
Date: Wed, 13 Mar 2013 16:27:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Imager::QRCode-ing octet sequences vs. zbarimg(1)
Message-Id: <u0m61a-t5i1.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> I wonder if QR codes are suitable for encoding arbitrary octet
> sequences (AKA 8-bit data)? I've tried the following Perl code,
> but it appears that the resulting transformations aren't "8-bit
> clean." Somehow, I suspect a QR::Imager fault, although
> zbarimg(1) may be responsible. (Unfortunately, the Perl module
> itself doesn't provide a decoder.)
There is a Perl decoder based on zbar (Barcode::ZBar), though presumably
it would behave the same as zbarimg.
[...]
>
> (The leading 51522d436f64653a and the trailing 0a after
> "Decoded:" are "QR-Code:" and a newline, respectively. In the
> first example, the first three octets in the output, 621d4f,
> appear to match the input. Incidentally, the fourth octet has
> its most significant bit set.)
>
> $ perl \
> 89br96tnpoogun68sfh1jkj1sb.perl # "use bytes;" commented out
> Blob:
> 621d4f87d3ae92b60932c96b7f81f3a916faff9b03ae54f97d8163987dc8733df1bd
> 8f8b92fb5317657ee2a0a97eed1f12423cdbfa1a73b3166a39cb4b1c0f43
> Image: 123 by 123
> Decoded:
> 51522d436f64653a621d4fc287c393c2aec292c2b60932c3896b7fc281c3b3c2a916
> c3bac3bfc29b03c2ae54c3b97dc28163c2987dc388733dc3b1c2bdc28fc28bc292c3
> bb5317657ec3a2c2a0c2a97ec3ad1f12423cc39bc3ba1a73c2b3166a39c38b4b1c0f
> 430a
> scanned 1 barcode symbols from 1 images in 0.02 seconds
~% perl -MEncode -E'say unpack "H*", encode "utf8", pack "H*",
"621d4f87d3ae92b60932c96b7"'
621d4fc287c393c2aec292c2b60932c3896b70
So you have a UTF-8 problem somewhere. (c2 and c3 (or  and Ã) showing
up unexpectedly is the giveaway here.) Looking at the code, I think it's
zbar which is converting 8859-1 to UTF-8; one way to test this is to
create a QR code containing 17 0xffs at ECC level L; this is the maximum
number of characters that will fit into a 21x21 QR code, so if the code
comes out bigger than that you know there are extra bytes in there
somewhere.
However, it's not unlikely that other QR code readers will do similar
conversions to UTF-8, or other stupid things. Depending on what you're
doing it might be safer to explicitly UTF-8-encode your data (all 8-bit
data can be represented in UTF-8) and then decode it on the other end.
Of course, this will make the codes a little larger than they need to
be.
[...]
> $ cat < 89br96tnpoogun68sfh1jkj1sb.perl
> use bytes;
You should not use 'bytes'. It doesn't ever do anything useful and
sometimes lets you look at parts of the perl internals you shouldn't be
looking at. In previous versions of perl the documentation was
unfortunately not very clear about that. The current version says
NOTICE
This pragma reflects early attempts to incorporate Unicode into perl
and has since been superseded. It breaks encapsulation (i.e. it
exposes the innards of how the perl executable currently happens to
store a string), and use of this module for anything other than
debugging purposes is strongly discouraged.
> use common::sense;
> use English;
You should not use English, it makes your code harder to read for anyone
who knows Perl, and teaches you bad habits.
>
> require Imager::QRCode;
> require IPC::Open2;
>
> sub rand_blob (;$) {
You should not use prototypes unless you need the special parsing
effects they cause.
> my ($len) = @_;
> $len
> //= 24;
> open (my $f, "<", "/dev/urandom")
> or die ($OS_ERROR);
> binmode ($f);
> my $s;
> die ($OS_ERROR)
> unless (read ($f, $s, $len) == $len);
> ## .
> $s;
> }
Unless you need cryptographic randomness (and since you're using
urandom, you don't), it would be better to use something like
sub rand_blob {
my ($len) = @_;
$len //= 24;
return join "", map chr rand 0xff, 0..$len;
}
Ben
------------------------------
Date: Thu, 14 Mar 2013 01:02:55 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <v6k71a-fhl1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> >> I totally disagree with the opinion that 'Perl 5 OO' would be 'rather
> >> >> a mess'. I usually undestand this as code language for 'it is
> >> >> different from $something I happen to be familiar with AND I
> >> >> ABSOLUTELY HATE THAT !!!!1', glossed over with pseudo-rationalization
> >> >> constructed in the usual, hackneyed way' ('the usual way' being
> >> >> 'emphasizing the disadvantages of the undesired something while
> >> >> ignoring the advantages, vice versa for the preferred something' and
> >> >> resorting to character assassination in order to discredit people who
> >> >> don't agree with this opinion).
> >> >
> >> > Oh dear. And for a minute there you were being so reasonable...
> >>
> >> 'Being reasonable' and 'agreeing with opinion X' are two very much
> >> different things.
> >
> > The first sentence I quoted I left in for context; it's not directly
> > pertinent to my reply. My problem is with the rest of the paragraph.
>
> 'Your problem' seems to be 'how to turn this away from Perl and into
> an [entirely personal] flamewar'
No. My problem is that you are refusing to behave reasonably. (You do
not have to agree with me in order to present your disagreement in a
reasonable fashion.) If you recall, the present discussion started with
you dismissing Moose in its entirety based on a rather poor
understanding of a single high-level concepts document, and in the
process being rather insulting about its authors. Since they are people
I respect (for purely technical reasons: I don't know any of them
personally) I object to seeing them insulted in public.
Once you stopped accusing anyone you disagree with of fascism and
intellectual dishonesty and started discussing the advantages,
disadvantages and techniques of Perl OO in a civilised and grown-up
fashion, I started taking what you are saying more seriously.
Unfortunately you now seem to have gone back to stamping your feet and
screaming incoherent gibberish, which makes that rather difficult.
> and the approach you seem to be
> taking, namely, suggesting that people who employ literary devices in
> a way you wouldn't, must clearly "be mad [!!2]" and hence, their
> opinions can be disregarded, isn't exactly 'new and creative'
> (searching for 'people hate perl' on the web easily uncovers texts
> which argue that 'Perl can be disregarded' because it was 'clearly
> designed by a total madman'
(It was. That's a feature.)
> based on the style of writing used in some
> of the published 'state of the onion' texts) and it is also illogical
> (not a great surprise): No statement about me, even if this statement
> happened to be true, enables any valid conclusions about any statement
> made by me: It could be 'truthful and valid' merely by
> coincidence.
Obviously. My comment about your behaviour was not any part of any
argument about Perl OO: it was a comment about your behaviour.
> NB: This obviously cuts both ways and my conviction that especially a
> lot of the more heated criticism about 'Perl OO' one can find on the
> web is - ultimatively - manifest xenophobia doesn't imply anything
> about the truthfulness of these statements either.
I don't give a damn what random people have written on the web about
Perl OO, or indeed about anything else. Much of the writing on the web
about Perl is utter nonsense; we all know that; I see no reason to take
any further notice of it. The fact that irrational criticism of Perl
exists should not prevent us from making rational criticism, especially
when discussing a framework designed to fix some perceived problems with
the way things currently work.
> But since you were
> essentially just repeating the party line, eg, the bit about 'keyword
> reuse' which can be found directly in the Perl 6 OO 'design
> apocalypse'
Um, was I? I wasn't aware there was a party line, nor that I was
repeating it; in particular I haven't read any of the Perl 6 design
documents in several years so I don't really remember any of the
details. I was, to some extent, repeating criticisms I have seen other,
competent, Perl 5 people make of Perl 5, but only because I found them
convincing.
I don't recall mentioning anything about keyword reuse; do you mean my
comment about the lack of distinction between subs and methods?
> (alongside 'second system done right' --- isn't it great
> how ambiguities in natural language always lend themselves to
> 'interesting alternate interpretations'?[*] --- Considering my opinion
> on Perl 6, 'design apocalypse' seems a very accurate label) a reply
> decomposing this text into 'high-level functional units' [a little],
> combined with a hint at their purpose, seemed appropriate.
OK, if I remove the parenthesis from that sentence I get
But since you were essentially just repeating the party line a reply
decomposing this text into 'high-level functional units' seemed
appropriate.
which is not something I can make sense of...
> Not the
> least because of your absolutely marvellous 'demonstration follow-up'.
>
> [*] I need to make an exception for 'It is too minimal' here. This is
> just plain nonsense --- the minimum may be too little or not enough
> but it can't be 'too minimal' since this already a superlative.
Yes, and 'optimisation' ought more properly to be called 'amelioration';
this is not how language works. 'Minimal' is now an English word, and it
doesn't mean quite the same thing as it meant in Latin.
Ben
------------------------------
Date: Thu, 14 Mar 2013 01:21:51 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87wqtabwsw.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> Once you stopped accusing anyone you disagree with of fascism
This is actually another classic, namely, the 'Have you stopped
beating your wife' question.
------------------------------
Date: Thu, 14 Mar 2013 01:36:41 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: message forwarding in perl
Message-Id: <87boam92za.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [...]
>
>> Once you stopped accusing anyone you disagree with of fascism
>
> This is actually another classic, namely, the 'Have you stopped
> beating your wife' question.
Absolutely last attempt at turning this back into a rational
discussion: Would you perhaps have the unbelievable kindness to stop
ventilating your totally unsubstantiated assumptions about me?
------------------------------
Date: Thu, 14 Mar 2013 02:53:57 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: message forwarding in perl
Message-Id: <5nq71a-qfm1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> > Ben Morrow <ben@morrow.me.uk> writes:
> >
> >> Once you stopped accusing anyone you disagree with of fascism
> >
> > This is actually another classic, namely, the 'Have you stopped
> > beating your wife' question.
>
> Absolutely last attempt at turning this back into a rational
> discussion: Would you perhaps have the unbelievable kindness to stop
> ventilating your totally unsubstantiated assumptions about me?
If you will do likewise. I am referring here to
I usually undestand this as code language for 'it is different from
$something I happen to be familiar with AND I ABSOLUTELY HATE THAT
!!!!1', glossed over with pseudo-rationalization constructed in the
usual, hackneyed way' ('the usual way' being 'emphasizing the
disadvantages of the undesired something while ignoring the
advantages, vice versa for the preferred something' and resorting to
character assassination in order to discredit people who don't agree
with this opinion).
and other comments of that nature.
Ben
------------------------------
Date: Wed, 13 Mar 2013 18:16:24 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: prototypes?
Message-Id: <87txofkvwn.fsf_-_@violet.siamics.net>
>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
>>>> sub rand_blob (;$) {
>>> You should not use prototypes unless you need the special parsing
>>> effects they cause.
>> Is there a practical reason to forgo the compile-time arguments'
>> type checking they offer? For me, code that fails to compile is
>> better than code that suddenly dies after running for hours.
> Prototypes are really only useful for 'compile-time argument
> checking' in code which circumvents the 'individual' ways Perl
> operators deal with their arguments by always putting them in
> brackets.
Are (parentheses) meant here, specifically? (As per the
Wiktionary entry, brackets may be {curly}, (round), [square], or
even <angle />.)
FWIW, I /always/ use parentheses for the function (subroutine)
arguments in my Perl code. Thus, the point is not to use
prototypes in the module's "public" interface?
> Otherwise, you'll be adding similar 'individual ways to deal with
> arguments' to your subroutines as a (probably undesired) side effect
> and this might confuse people who expect all subroutines to behave
> identical when not bracketing the arguments.
ACK, thanks! And now I see it's explained (although perhaps
without the amount of warnings this issue seem to deserve) in
perlsub(1).
[...]
--
FSF associate member #7257
------------------------------
Date: Wed, 13 Mar 2013 18:54:59 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: prototypes?
Message-Id: <87txofi0zg.fsf@sapphire.mobileactivedefense.com>
Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>>> Ivan Shmakov <oneingray@gmail.com> writes: [...]
[...]
> >> Is there a practical reason to forgo the compile-time arguments'
> >> type checking they offer? For me, code that fails to compile is
> >> better than code that suddenly dies after running for hours.
>
> > Prototypes are really only useful for 'compile-time argument
> > checking' in code which circumvents the 'individual' ways Perl
> > operators deal with their arguments by always putting them in
> > brackets.
>
> Are (parentheses) meant here, specifically? (As per the
> Wiktionary entry, brackets may be {curly}, (round), [square], or
> even <angle />.)
>
> FWIW, I /always/ use parentheses for the function (subroutine)
> arguments in my Perl code. Thus, the point is not to use
> prototypes in the module's "public" interface?
>
> > Otherwise, you'll be adding similar 'individual ways to deal with
> > arguments' to your subroutines as a (probably undesired) side effect
> > and this might confuse people who expect all subroutines to behave
> > identical when not bracketing the arguments.
>
> ACK, thanks! And now I see it's explained (although perhaps
> without the amount of warnings this issue seem to deserve) in
> perlsub(1).
Issue I forgot about (mentioning it clearly): Prototypes also enforce
an evaluation context for arguments, eg
perl -e 'sub blah { print $_[0], "\n";} @bla = qw(3 2); blah(@bla)'
3
This prints 3 because 3 is the first element of @bla but
perl -e 'sub blah($) { print $_[0], "\n";} @bla = qw(3 2); blah(@bla)'
2
this prints 2 because it evaluates @bla in scalar context which yields
the number of elements in it.
------------------------------
Date: Wed, 13 Mar 2013 22:49:24 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: prototypes?
Message-Id: <87ehfij4p7.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ivan Shmakov <oneingray@gmail.com> writes:
>>>>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
>>>> Is there a practical reason to forgo the compile-time arguments'
>>>> type checking they offer? For me, code that fails to compile is
>>>> better than code that suddenly dies after running for hours.
>>> Prototypes are really only useful for
[...]
> Prototypes also enforce an evaluation context for arguments, eg
My opinion on this is that I don't care about being able to emulate
the IMHO too idiosyncratic way in which the syntax of different
built-in Perl operators has been 'hand-optimized' and that I also
don't care about the fact itself. Further, I can live with the minor
nuisance that passing an array (or a hash) to a subroutine with a
prototype enforcing scalar context does not result in passing a list
of arguments to this subroutine, especially considering that this
doesn't consistently work for built-in operators as well, eg, sprintf,
when I get at least some kind of compile-time checking of subroutine
calls in return. I also usually use a Makefile to run perl -cw
-Mstrict on any changed Perl file of even the most remotely
non-trivial 'Perl project' prior to attempting any 'runtime
testing'. Considering that no such checking is possible for method
calls, this may not really be a worthwhile tradeoff but rather a habit
of mine I carried over from C. But I'm not convinced of this yet.
OTOH, this is decidedly not the opinion of the people who removed the
"if it looks like a function, it will work like a function" statement
from the Perl documentation (or who agreed that this would be a good
idea). Since these also generally don't believe that people do
something like 'separate compile time checks' at all and can get
pretty much arbitrarily nasty when being confronted with opinions they
don't approve of, I - as I already wrote - usually just delete any
prototypes when I include code 'from other sources' in postings to the
group.
------------------------------
Date: Thu, 14 Mar 2013 01:10:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: prototypes?
Message-Id: <ikk71a-fhl1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> OTOH, this is decidedly not the opinion of the people who removed the
> "if it looks like a function, it will work like a function" statement
> from the Perl documentation
~/src/perl/perl/pod% ack 'like a function'
perlsyn.pod
78:back into something that behaves more like a function call.
perlfunc.pod
34:surprising rule is this: It I<looks> like a function, therefore
412:These operators are exempt from the "looks like a function rule"
perl56delta.pod
2672:The C<not> operator now falls under the "if it looks like a function,
2673:it behaves like a function" rule.
perl561delta.pod
3277:The C<not> operator now falls under the "if it looks like a function,
3278:it behaves like a function" rule.
Ben
------------------------------
Date: Thu, 14 Mar 2013 01:40:56 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: prototypes?
Message-Id: <877gla92s7.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> OTOH, this is decidedly not the opinion of the people who removed the
>> "if it looks like a function, it will work like a function" statement
>> from the Perl documentation
>
> ~/src/perl/perl/pod% ack 'like a function'
> perlsyn.pod
> 78:back into something that behaves more like a function call.
>
> perlfunc.pod
> 34:surprising rule is this: It I<looks> like a function, therefore
> 412:These operators are exempt from the "looks like a function rule"
>
> perl56delta.pod
> 2672:The C<not> operator now falls under the "if it looks like a function,
> 2673:it behaves like a function" rule.
>
> perl561delta.pod
> 3277:The C<not> operator now falls under the "if it looks like a function,
> 3278:it behaves like a function" rule
Some more reference to 'clean up', I guess ...
------------------------------
Date: Thu, 14 Mar 2013 03:04:19 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: prototypes?
Message-Id: <jar71a-qfm1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >>
> >> OTOH, this is decidedly not the opinion of the people who removed the
> >> "if it looks like a function, it will work like a function" statement
> >> from the Perl documentation
> >
> > ~/src/perl/perl/pod% ack 'like a function'
[...]
> > perlfunc.pod
> > 34:surprising rule is this: It I<looks> like a function, therefore
[...]
>
> Some more reference to 'clean up', I guess ...
(Oh, for God's sake...)
This section of perlfunc
If you use parentheses, the simple but occasionally surprising rule
is this: It I<looks> like a function, therefore it I<is> a function,
and precedence doesn't matter. Otherwise it's a list operator or
unary operator, and precedence does matter.
is the original source of that phrasing of the rule, and has been there
unchanged (except for a minor adjustment to the punctuation in 2010)
since the release of perl 5.000.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3900
***************************************
