[31611] in Perl-Users-Digest
Perl-Users Digest, Issue: 2870 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 11 18:09:28 2010
Date: Thu, 11 Mar 2010 15:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 11 Mar 2010 Volume: 11 Number: 2870
Today's topics:
Re: to RG - Lisp lunacy and Perl psychosis <m@rtij.nl.invlalid>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: Web Based Perl Courses <john@castleamber.com>
Re: Well, that's the most obscure Perl bug I've ever se <ben@morrow.me.uk>
Re: Well, that's the most obscure Perl bug I've ever se <uri@StemSystems.com>
Re: Well, that's the most obscure Perl bug I've ever se <willem@turtle.stack.nl>
Re: Well, that's the most obscure Perl bug I've ever se <sherm@debian.shermpendley.com>
Re: Well, that's the most obscure Perl bug I've ever se <smallpond@juno.com>
Re: Well, that's the most obscure Perl bug I've ever se <ben@morrow.me.uk>
Re: Well, that's the most obscure Perl bug I've ever se <nospam-abuse@ilyaz.org>
Re: Well, that's the most obscure Perl bug I've ever se <sreservoir@gmail.com>
Re: Well, that's the most obscure Perl bug I've ever se <KBfoMe@realdomain.net>
Re: Well, that's the most obscure Perl bug I've ever se <no-one@unknown.com>
Re: Writing to the end of a record <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 11 Mar 2010 21:57:43 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <732o67-cj6.ln1@news.rtij.nl>
On Wed, 10 Mar 2010 16:41:27 -0800, Ron Garret wrote:
> Why must those be the only possibilities? It was because the Perl code,
> which had been working fine for months, suddenly started failing
> silently and intermittently, and I was told there was no way to do the
> equivalent of wrapping the whole script in the equivalent of a
> TRY...EXCEPT form in order to catch the error. Whether this was in fact
> true or whether the entire engineering team was incompetent I do not
> know. But they seemed pretty bright and capable otherwise, so it would
> be pretty odd for them all to be mistaken about this.
If they didn't know about eval { original code here };, they were
incompetent. But there were probably other factors at work you didn't
tell about.
M4
------------------------------
Date: Thu, 11 Mar 2010 23:28:40 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhpirku.i4n.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-10 17:45, Ron Garret <rNOSPAMon@flownet.com> wrote:
> Most of what I have to say about this has already been said by other
> people, but since this post is addressed specifically to me I'll respond
> nonetheless.
>
> In article
><19c5b00d-c1e0-4016-9f72-37229cbf42b9@g19g2000yqe.googlegroups.com>,
> ccc31807 <cartercc@gmail.com> wrote:
>
>> On February 27, in a thread on c.l.l, RG had this to say about Perl:
>> <quote>
>> >> But Perl is just an
>> >> abomination through-and-through. I do not deny that many people find it
>> >> a productive tool, and about ten years ago having developed a certain
>> >> level of respect for some of those people I determined to learn Perl
>> >> just to see what those people got out of it. So I picked up a Perl
>> >> book, but I could not get past the first few chapters without recoiling
>> >> in revulsion. It was just horrible.
>> </quote>
>> I wanted to reply but also wanted to take some time to think about my
>> reply.
[long fullquote deleted - please quote only the parts necessary for
context]
>> One language isn't better or worse that the other, they are just
>> different, and the expression of RG's opinion is simply a value
>> judgment, which others may or may not share.
>
> Certainly my opinion is only my opinion. But in my opinion it is not
> true that "one language isn't better or worse than the other."
> Brainf*ck, Whitespace, and Unlambda, for example, were specifically
> designed to be bad languages, and they are.
Agreed.
> Perl was not specifically designed to be a bad language, but it is
> (IMHO of course) for many of the same reasons that the aforementioned
> languages are bad.
I don't think so. It doesn't meet your aesthetic criteria, but it is a
powerful programming language which can be used to write everything from
simple throwaway scripts to large, complex software systems, in a
readable, testable, maintainable way.
It is true that the syntax is rather complex - probably one of the most
complex ones in popular programming languages. This is intentional:
Firstly, because Larry tried to throw all the good bits from lots of
programming languages in (when I first encountered Perl I called it
"the PL/1 of nineties"), and partly because he modelled it after natural
languages, so like natural languages it has a complex, irregular,
context-sensitive syntax with lots of shortcuts. He probably went too
far - Perl syntax could be cleaner and less visually cluttered without
losing expressivity.
Lisp is the opposite - it has an extremely minimalistic syntax, and for my
taste it goes too far in the direction of simplicity and purity. A lisp
program may be easy to read for a lisp compiler, but it isn't easy to
read for me. I need more visual structure.
> You write:
>
>> I think any journeyman programmer can follow the logic even if he
>> doesn't understand Perl or the data structures
>
> Maybe I don't qualify as a journeyman I can't follow that Perl code, and
> for exactly the same reason that I can't follow Brainf*ck code: too much
> punctuation. What does !~ mean? What do the curly braces denote? What
> is /\d/? And if I don't know the answers, how do I look them up? (Yes,
> I tried Perldoc. It didn't help.)
Well, all of these are described in perldoc, so I don't understand why
reading it didn't help.
> The Lisp code, by contrast, has only three items of punctuation that I
> have to understand: parentheses, double quotes, and the colon. All the
> rest is English words. Some of those words might be mysterious (like
> CONS) but at least I can plug those into a search engine to obtain
> additional clues. And the double quotes mean exactly what they mean in
> common usage, so that leaves only two punctuation marks to deal with.
That doesn't necessarily make the language easier to learn or read.
On the contrary, I think lisp offers too few visual clues - everything
looks the same to me. (but then I've never used lisp in anger, so in
part this is simply because I'm not used to it)
> Also, others have mentioned this but it's worth reiterating: you've
> taken actual working Perl code and compared it to a Lisp example
> specifically designed to be pathological.
While Carter's code wasn't specifically designed to be pathological it
was pretty bad, too.
But how would the same code look in well-written Lisp? (Ben already
showed well-written Perl).
>> Perl uses sigils ($, !, %, &) to signify a token's usage.
>
> No, Perl uses sigils to indicate a variable's data type, not a token's
> usage. Except that it doesn't.
Right. It doesn't do that but for a completely different reason:
The sigil has (almost) nothing to do with the variable's data type.
Instead it is an article, like in many European languages.
English is a bad example, because it has only one definite article
(the), so let's use Italian:
il - singular male
la - singular female
i - plural male
le - plural female
Gender doesn't have any meaning in Perl, but we can distinguish between
singular ($) and plural. And there are two types of plural - ordered
(lists, arrays: @) and unordered (hashes: %).
So $ denotes singular:
$ x - one x
$ a[2] - one element (with index 2) of the array a
$ h{'k'} - one element (with key 'k') of the hash h
@ denotes an ordered plural:
@ a - the whole array a
@ h{'a', 'c', 'b'} - the elements with keys 'a', 'c', 'b' of hash h, in
that order.
% denotes an unordered plural:
% h - the whole hash h
Note that I have used $ with a scalar variable, an array variable and a
hash variable and I have used @ with both an array variable and a hash
variable. So they clearly don't "indicate the type of the variable".
I have written a space after the sigil to emphasize that it is a "word"
in Perl's grammar and not a part of the variable name. Normally you omit
the space.
(Side note: Sigils are used differently in Perl6)
> It distinguishes between scalars, lists, and hash tables,
Yes, but in a different way than you seem to think. Also, these three
are rather fundamentally different (although awk and JavaScript seem to
think that hashes and arrays are the same thing).
> but not between integers, floats, and strings.
Right. It doesn't do that. Should it? From a performance POV maybe - a
4byte int takes a lot less memory than a perl scalar value. But from a
correctness POV using representative types doesn't buy you much - you
may represent both the area of your living room and the milage of your
car as a floating point number but that doesn't mean that the sum of
both makes any sense. For that you need a much more strict type model.
> It distinguishes between strings and regular expressions,
No, not really. At least not any more than it distinguishes between
numbers and strings. And that distinction is relatively recent.
> but not between strings and code.
Huh? Yes, it does. You can compile a string into code, but you'll have
to do that explicitely.
> It has all kinds of weird punctuationy things that you can't look up,
> like $@ and !~ and <>.
Of course you can look them up. All of them are documented and the Perl
docs aren't that bad (although I agree that they could be better). You
can't use google to search for them, but the same is true for any
keyword or variable name which happens to be a common English word
(although for opposite reasons).
> It fails silently where it should produce errors.
That's debatable. Perl is in the C tradition of returning an error value
instead of throwing an exception, but that is only "silent" if the
Programmer carelessly ignores the return value.
> It violates universally accepted conventions
> about what, for example, double quotes mean. For example, this:
>
> print "The widget costs $12.75.";
>
> The actual behavior of that code snippet is not justifiable under any
> sane language semantics.
"Universally accepted" is rather strong given that most shells, most
templating languages and many scripting languages use a similar
expansion mechanism.
The expansion mechanism in Perl has a few shortcomings, but the fact
that Perl has such a mechanism is a feature, not a bug. Apart from a few
pathological examples like the one above, simply embedding variables or
(very) simple expressions in a string is less cluttered and easier to
read then constructing the string with concatenation operators or
formatting functions. And Perl *does* have simple strings, you know.
hp
------------------------------
Date: Thu, 11 Mar 2010 23:48:45 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhpisqf.i4n.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-11 00:41, Ron Garret <rNOSPAMon@flownet.com> wrote:
> In article
><ce68ccd0-22e2-472d-9cc3-06a2cf00a29f@y11g2000yqh.googlegroups.com>,
> ccc31807 <cartercc@gmail.com> wrote:
>> > I've had one firsthand
>> > experience with Perl in production that turned out very badly.
>>
>> Was that because Perl was a bad match for the project? Or because the
>> developers were incompetent in Perl?
>
> Why must those be the only possibilities? It was because the Perl code,
> which had been working fine for months, suddenly started failing
> silently and intermittently, and I was told there was no way to do the
> equivalent of wrapping the whole script in the equivalent of a
> TRY...EXCEPT form in order to catch the error. Whether this was in fact
> true or whether the entire engineering team was incompetent I do not
> know. But they seemed pretty bright and capable otherwise, so it would
> be pretty odd for them all to be mistaken about this.
Well, they were wrong, but Perl doesn't throw exceptions silently. When
a Perl program dies, you get a message telling you exactly where and
why.
So when the program "failed silently and intermittently" there was
probably some error in the program logic which caused it to exit
prematurely. Wrapping the whole script in eval{} doesn't help here
because no exception is thrown. You'll have to analyze the logic flow of
the program to find that - I don't think that's any different in lisp
(yes, lisp is (or was) very popular in AI research, but automatically
finding logical errors in programs is still an unsolved problem, AFAIK).
Perl comes with a simple framework for unit tests. And because it comes
with Perl and is so simple to use, it is very common for Perl
programmers to write tests. There are also various ways to trace program
execution (from simple print statements to log4perl to smart comments to
running the whole thing in the debugger).
If your colleagues didn't use the tools they had and just said "it
doesn't work and we don't know why and can't find out" I'd call them
incompetent. But I don't know what they did, so I won't.
In any case I very much doubt that it is much easier to find the bug in
a lisp program which "suddenly started failing silently and
intermittently" than in a Perl program which does the same.
hp
------------------------------
Date: Thu, 11 Mar 2010 23:54:59 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhpit64.i4n.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-10 20:20, ccc31807 <cartercc@gmail.com> wrote:
> On Mar 10, 1:48 pm, Jürgen Exner <jurge...@hotmail.com> wrote:
>> That code is abominable and obfuscated, but of course you can write
>> abominable and obfuscated code in any programming language.
>
> That code is hard read, but it's not obfuscated. The variable 'names'
> represent scalar values, in this case, an 'integer' used as a key. The
> convoluation comes from Perl's awkward syntax for multi-level data
> structures,
Now I'm curious: How is Perl's syntax for multi-level data structures
awkward? Which language does it in a less awkward way? I'd like to see
your code snippet translated into a "less awkward" language.
(I do find the dereferencing of array and hash refs awkward, but you
didn't use that here)
hp
------------------------------
Date: Thu, 11 Mar 2010 13:26:47 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Web Based Perl Courses
Message-Id: <87aaueslqg.fsf@castleamber.com>
"Uri Guttman" <uri@StemSystems.com> writes:
> but the o'reilly school of technology (yes, the publisher) has just
> released their perl level 1 class and are planning something like 5-6
> levels. these come with continuing education credits from a real
> university as well. i recommend them as i know the author well (peter
> scott) and he is very good at perl training. there are current discounts
> on the course so tell your colleague about them.
http://www.oreillyschool.com/courses/
thanks Uri
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Thu, 11 Mar 2010 19:14:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <11sn67-rem1.ln1@osiris.mauzo.dyndns.org>
Quoth Frank Seitz <devnull4711@web.de>:
> Uri Guttman wrote:
> >>>>>> "FS" == Frank Seitz <devnull4711@web.de> writes:
> >
> > FS> Yes, this is what I meant. The conversion makes sense because
> > FS> a reference is basically a memory address (plus type),
> > FS> and a memory address is an integer.
> >
> > to be clear, a ref will return a number (the address) in a numeric
> > context or the TYPE(0xfdddd) style in a string context. it is not a
> > number but a multivalued thing that returns different things in
> > different contexts. it is a ref, number AND string all in the same
> > scalar if you want to see it that way. but once you modify it with ++ it
> > becomes only a number thereafter.
>
> Very good explanation, except that I would not say that
> a reference "returns" something, because it is a (passive) data structure.
There's no such thing in Perl. Evaluating a ref in numeric context
numifies it. It's the same as
float a;
int b = 3;
a = b;
in C, which is actually an implicit function call (though Perl caches
the result, which C doesn't).
Ben
------------------------------
Date: Thu, 11 Mar 2010 14:18:57 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <87sk86u0ny.fsf@quad.sysarch.com>
>>>>> "FS" == Frank Seitz <devnull4711@web.de> writes:
FS> Uri Guttman wrote:
>>>>>>> "FS" == Frank Seitz <devnull4711@web.de> writes:
>>
FS> Yes, this is what I meant. The conversion makes sense because
FS> a reference is basically a memory address (plus type),
FS> and a memory address is an integer.
>>
>> to be clear, a ref will return a number (the address) in a numeric
>> context or the TYPE(0xfdddd) style in a string context. it is not a
>> number but a multivalued thing that returns different things in
>> different contexts. it is a ref, number AND string all in the same
>> scalar if you want to see it that way. but once you modify it with ++ it
>> becomes only a number thereafter.
FS> Very good explanation, except that I would not say that
FS> a reference "returns" something, because it is a (passive) data structure.
hard to find a better word for what a value is in different
contexts. returns seems to work even though it isn't a sub. you can say
the same for a sub that checks wantarray or other things that 'return'
different values in different contexts (e.g. arrays). how would you say
this?
arrays return their size in scalar context and a list of their elements
in list context.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 11 Mar 2010 19:28:03 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhpih23.hk5.willem@turtle.stack.nl>
Ben Morrow wrote:
) There's no such thing in Perl. Evaluating a ref in numeric context
) numifies it. It's the same as
)
) float a;
) int b = 3;
) a = b;
)
) in C, which is actually an implicit function call (though Perl caches
) the result, which C doesn't).
How do you know it doesn't ? The optimizer is allowed to do
anything it pleases as long as the end effect is the same.
Caching results of function calls that are known not to have
side effects is one very common optimization.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 11 Mar 2010 15:07:17 -0500
From: Sherm Pendley <sherm@debian.shermpendley.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <87wrxityfe.fsf@debian.shermpendley.com>
pete <no-one@unknown.com> writes:
> On Thu, 11 Mar 2010 14:19:26 +0100, ace wrote:
>> pete wrote:
>>> j = 7
>>> j = 8
>>> j = 9
>>> j = 10, i=6308506
>>>
>>> Yup, it's that solitary "$" all alone in the middle of nowhere.
>>> it only took me about an hour and a half to spot - probably because
>>> I was looking in entirely the wrong place as the real-life code had
>>> a large block of comment lines between the "$" and "$i = 0;"
>>
>> It's your own fault actually. Put use strict; on top of your program and
>> try to reproduce misbehavior.
>
> Not practical
So, spending an hour and a half chasing down a bug that Perl could have
found for you in less than a second *is* practical?
I think we define that word differently...
sherm--
------------------------------
Date: Thu, 11 Mar 2010 15:36:16 -0500
From: Steve C <smallpond@juno.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <hnbk8g$h0s$1@news.eternal-september.org>
pete wrote:
> On Thu, 11 Mar 2010 14:19:26 +0100, ace wrote:
>> pete wrote:
>>> j = 7
>>> j = 8
>>> j = 9
>>> j = 10, i=6308506
>>>
>>> Yup, it's that solitary "$" all alone in the middle of nowhere.
>>> it only took me about an hour and a half to spot - probably because
>>> I was looking in entirely the wrong place as the real-life code had
>>> a large block of comment lines between the "$" and "$i = 0;"
>> It's your own fault actually. Put use strict; on top of your program and
>> try to reproduce misbehavior.
>
> Not practical - it's not my original code, just my original bug :-(
Not a very good excuse. You don't even have to change the code:
perl pete
j = 0
j = 1
j = 2
j = 3
j = 4
j = 5
j = 6
j = 7
j = 8
j = 9
j = 10, i=147926066
perl -w -Mstrict pete
Global symbol "$i" requires explicit package name at pete line 4.
Global symbol "$j" requires explicit package name at pete line 6.
Global symbol "$j" requires explicit package name at pete line 6.
Global symbol "$j" requires explicit package name at pete line 6.
Global symbol "$j" requires explicit package name at pete line 7.
Global symbol "$i" requires explicit package name at pete line 8.
Global symbol "$j" requires explicit package name at pete line 10.
Global symbol "$i" requires explicit package name at pete line 10.
Execution of pete aborted due to compilation errors.
------------------------------
Date: Thu, 11 Mar 2010 20:54:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <8t1o67-u9n1.ln1@osiris.mauzo.dyndns.org>
Quoth pete <no-one@unknown.com>:
> On Thu, 11 Mar 2010 14:19:26 +0100, ace wrote:
> >
> > It's your own fault actually. Put use strict; on top of your program and
> > try to reproduce misbehavior.
Strict wouldn't have helped in this case if the variable was declared
already but happened to contain undef:
use strict;
my $x;
...
$
#comment
$x = 1;
The only solution to this sort of problem is to keep your code in source
control, and make small commits. That way, when you break something you
can just 'git diff' or whatever and clearly see what you've changed
since last time it worked.
> Not practical - it's not my original code, just my original bug :-(
It's really not that difficult to do a minimal job. Add 'use strict;',
then keep adding 'my $foo' or 'our $foo' at the top of the file until it
stops complaining about undeclared variables. Anything nasty like
symrefs can be wrapped in an appropriate 'no strict' block.
The result won't be *good* code, but it'll be better than what you had
before and it'll stop you introducing new bugs without meaning to. You
can get round to fixing up the scoping of each piece of code as you come
to it.
Ben
------------------------------
Date: Thu, 11 Mar 2010 21:13:28 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhpin7o.6dj.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-03-11, Glenn Jackman <glennj@ncf.ca> wrote:
>> >>> What surprised me was that perl didn't see
>> >>> the $<extraneous stuff+whitespace># ...
>> >>> and try to calculate the size of an array named by the comment, thus:
>> >>>
>> >>> $# set ...
>> >>> $i = 0;
I agree with the surprise...
>> >>> which would at least have spat out a syntax error
>> >>
>> >> "# set ..." is a comment and is ignored by Perl.
>> >
>> > You miss pete's point, which was that the "#" was part of "$#...".
>> >
>> > "$#set" is the last index of the @set array.
>> >
>> > "$# set" is a syntax error.
>>
>> I talked about the original code. In that code is whitespace
^^^^^^^^^^
No. I do not see whitespace there. What I see is "whitespace
interspersed with comments"; this is a different syntaxical element.
>> between the $ and the #, i.e. # starts a comment.
^^^^^^^^^^^^^^^^^^
How does one know? One cannot...
> We can ask perl what it sees:
>
> perl -MO=Deparse -e '
> $
> # a comment
> $i = 0;
> print $i;
> '
>
> which gives
>
> $$i = 0;
> print $i;
> -e syntax OK
You can ask a particular COMPILE of a particular PORT of a particular
VERSION of perl. Given that the observed behaviour is obviously a
bug, you cannot expect that any other guy would reproduce anything
similar... Experimentation has very little value as a path to a
definitive answer.
The only recourse is looking for documentation, but as we all know,
Perl is practically undocumented...
===
Let me sum up: IMO, the bug is in Perl, and not in the script. The
particular construct should not allow interspersed comments.
Hope this helps,
Ilya
------------------------------
Date: Thu, 11 Mar 2010 16:30:29 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <hnbndt$902$1@speranza.aioe.org>
On 3/11/2010 4:13 PM, Ilya Zakharevich wrote:
> On 2010-03-11, Glenn Jackman<glennj@ncf.ca> wrote:
>>>>>> What surprised me was that perl didn't see
>>>>>> the $<extraneous stuff+whitespace># ...
>>>>>> and try to calculate the size of an array named by the comment, thus:
>>>>>>
>>>>>> $# set ...
>>>>>> $i = 0;
>
> I agree with the surprise...
>
>>>>>> which would at least have spat out a syntax error
>>>>>
>>>>> "# set ..." is a comment and is ignored by Perl.
>>>>
>>>> You miss pete's point, which was that the "#" was part of "$#...".
>>>>
>>>> "$#set" is the last index of the @set array.
>>>>
>>>> "$# set" is a syntax error.
>>>
>>> I talked about the original code. In that code is whitespace
> ^^^^^^^^^^
>
> No. I do not see whitespace there. What I see is "whitespace
> interspersed with comments"; this is a different syntaxical element.
>
>>> between the $ and the #, i.e. # starts a comment.
> ^^^^^^^^^^^^^^^^^^
>
> How does one know? One cannot...
>
>> We can ask perl what it sees:
>>
>> perl -MO=Deparse -e '
>> $
>> # a comment
>> $i = 0;
>> print $i;
>> '
>>
>> which gives
>>
>> $$i = 0;
>> print $i;
>> -e syntax OK
>
> You can ask a particular COMPILE of a particular PORT of a particular
> VERSION of perl. Given that the observed behaviour is obviously a
> bug, you cannot expect that any other guy would reproduce anything
> similar... Experimentation has very little value as a path to a
> definitive answer.
>
> The only recourse is looking for documentation, but as we all know,
> Perl is practically undocumented...
>
> ===
>
> Let me sum up: IMO, the bug is in Perl, and not in the script. The
> particular construct should not allow interspersed comments.
The particular construct really shouldn't allow all sorts of things it
does.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Thu, 11 Mar 2010 15:51:37 -0600
From: "Kyle T. Jones" <KBfoMe@realdomain.net>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <hnbol9$bpd$1@news.eternal-september.org>
jl_post@hotmail.com wrote:
> It wasn't easy adding "use strict" and "use warnings" to the files,
> but now maintaining the scripts is about ten times easier.
>
Why wasn't it easy? Surely you didn't go through and do it manually?
Uhhh, is this that "irony" thing my friends are always going on about?
Cheers.
------------------------------
Date: Thu, 11 Mar 2010 22:39:26 GMT
From: pete <no-one@unknown.com>
Subject: Re: Well, that's the most obscure Perl bug I've ever seen
Message-Id: <slrnhpis8u.n7d.no-one@corv.local>
On Thu, 11 Mar 2010 15:07:17 -0500, Sherm Pendley wrote:
> pete <no-one@unknown.com> writes:
>
>> On Thu, 11 Mar 2010 14:19:26 +0100, ace wrote:
>>> pete wrote:
>>>> j = 7
>>>> j = 8
>>>> j = 9
>>>> j = 10, i=6308506
>>>>
>>>> Yup, it's that solitary "$" all alone in the middle of nowhere.
>>>> it only took me about an hour and a half to spot - probably because
>>>> I was looking in entirely the wrong place as the real-life code had
>>>> a large block of comment lines between the "$" and "$i = 0;"
>>>
>>> It's your own fault actually. Put use strict; on top of your program and
>>> try to reproduce misbehavior.
>>
>> Not practical
>
> So, spending an hour and a half chasing down a bug that Perl could have
> found for you in less than a second *is* practical?
>
> I think we define that word differently...
>
Nooo, we define the word the asme. The difference is when you add something
to a few hundred lines of old Perl and then have to spend the rest of the
day nailing each particular non-strict complaint in turn. Then hoping I
don't break something else along the way. Then retesting all the stuff I've
changed instead of just testing the stuff I've added. It could easily turn
a half-day job into a week of work - if done properly, on hourly rates :-)
------------------------------
Date: Thu, 11 Mar 2010 19:15:34 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Writing to the end of a record
Message-Id: <m3sn67-rem1.ln1@osiris.mauzo.dyndns.org>
Quoth Joe <jruffino@gailborden.info>:
>
> I am trying to write to the end of a record once I find the data
> needed, but everything I have tried and the Internet is no real help.
>
> I open my data file by using 'open (LOCATE +<$filename') and the data
That isn't Perl.
> is processed correctly when a match is found. It is when I try to
> write to the end is when I have trouble.
>
> I have tried, using 'print LOCATE ($_ . ", done")', but when I run the
> program the data is never written to the file
>
> If someone could tell me what i am doing wrong, I would really
> appreciate it.
Post your code. If it's long, cut it down to a minimal example which
still fails, and post that.
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 2870
***************************************
