Most obscure feature in Perl
Ross Clement
What feature of perl (syntax or built in function) is the most obscure/least
intuitive? By this, I mean a basic, common, feature of the language, not
a library or mmodule.
Cheers,
Ross-c
Graham W. Boyes - HawHawJokes.com
> What feature of perl (syntax or built in function) is the most obscure/least
> intuitive? By this, I mean a basic, common, feature of the language, not
> a library or mmodule.
How about the part that makes it go "Premature End of Script Headers"......
Graham
--
Receive clean jokes in your inbox daily! Just send an e-mail to: subscribe AT
hawhawjokes DOT com
Ross Clement
: Thus quoth Ross Clement:
: > What feature of perl (syntax or built in function) is the most obscure/least
: > intuitive? By this, I mean a basic, common, feature of the language, not
: > a library or mmodule.
:
: How about the part that makes it go "Premature End of Script Headers"......
Hmmm.... I was meaning something that was built into the language as a
functional feature, not an error condition. No matter how unhelpful the
error condition.
E.g. the default variable $_ is pretty obscure. But, IMHO it's really too well
known for it to be the most obscure feature in the language.
Cheers,
Ross-c
Steffen Müller
news:3ce12ff0$1...@isls-news.wmin.ac.uk...
To a Perl beginner who's also learning to program for the first time, I
guess pack/unpack or binary logic (vec, etc.) are the hardest to grasp. For
a C veteran, they'll be trivial.
A Unix hacker will find the *nix like system commands intuitive. Somebody
used to a Windows environment won't.
Maybe precedence causes the most trouble overall.
Steffen
--
@n=(544290696690,305106661574,116357),$b=16,@c=' ,JPacehklnorstu'=~
/./g;for$n(@n){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}c(0..9);
push@p,map{$c[$_]}@c[c($b..$#c)];$#c=$b-1}print@p;sub'c{reverse @_}
Peter Hickman
>To a Perl beginner who's also learning to program for the first time, I
>guess pack/unpack or binary logic (vec, etc.) are the hardest to grasp. For
>a C veteran, they'll be trivial.
>
Pack/unpack still get me!
Godzilla!
(snipped)
> What feature of perl (syntax or built in function) is the most obscure/least
> intuitive? By this, I mean a basic, common, feature of the language, not
> a library or mmodule.
This idiotic addition of an "our" declaration.
Our word "our" is indicative of possession by all,
intuitively, a global inflection.
Nonetheless, those developing perl core inanely
added this declaration with an intent to replace
perl core's "local" declaration and, most inanely,
to satisfy the needs of an independent module, strict.
"Our" does not intuitively indicate local.
"Our" does not intuitively indicate module usage.
strict ($global_variable) = "whatever";
This makes sense although absolutely inane.
Clearly those developing perl core would not be noted
for exceptional understanding of written language usage.
It is equally clear writing perl core to meet needs of
a module written by an independent author, is illogical.
Godzilla!
--
Roberta The Remarkable Robot, Mistress Of Mind Munching!
http://la.znet.com/~callgirl/roberta/roberta.cgi
Chahta Chat, The Most Entertaining Chat To Be Found!
http://la.znet.com/~callgirl/webchat/chahta.cgi
Brian McCauley
> Ross Clement wrote:
>
> (snipped)
>
> > What feature of perl (syntax or built in function) is the most obscure/least
> > intuitive? By this, I mean a basic, common, feature of the language, not
> > a library or mmodule.
>
> This idiotic addition of an "our" declaration.
I'm actually inclined to agree.
> Our word "our" is indicative of possession by all,
Saying that I refer to the instance of something which is possesed
jointly by me and all the other blocks of code within the same
package.
> Nonetheless, those developing perl core inanely
> added this declaration with an intent to replace
> perl core's "local" declaration
our() is in no way a replacement for local()
I suppose the fact that you are talking rubbish here, ironically, goes
to support your thesis that our() is obscure and counter-intuative!
our() is a replacement for 'use vars'.
> "Our" does not intuitively indicate local.
By "local" do you mean "lexical scope" or are you just confused about
what our() actually does. I argee that the fact that our()'s effect
is lexically scoped may be counter to some people's intuition.
> "Our" does not intuitively indicate module usage.
By "module" I shall assume you mean "package". I agree.
> strict ($global_variable) = "whatever";
>
> This makes sense although absolutely inane.
No strict it makes no more sense than our().
> Clearly those developing perl core would not be noted
> for exceptional understanding of written language usage.
Er... pot... kettle... black.
> It is equally clear writing perl core to meet needs of
> a module written by an independent author, is illogical.
"strict" is a pragmatic module that largely provides nothing more than
an interface to switch off (sic) functionality[1] that is part of the
core but which is switched on by default.
[1] Symbolic referenecs, implicit quoting of barewords, implicit
declaration of package variables.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
Brian McCauley
> What feature of perl (syntax or built in function) is the most obscure/least
> intuitive? By this, I mean a basic, common, feature of the language, not
> a library or mmodule.
I think the difference between (eof) and (eof()) is a good candidate.
Godzilla!
> Godzilla! wrote:
> > Ross Clement wrote:
(snipped)
> > > What feature of perl (syntax or built in function) is the most obscure/least
> > > intuitive? By this, I mean a basic, common, feature of the language, not
> > > a library or mmodule.
> > This idiotic addition of an "our" declaration.
> I'm actually inclined to agree.
You are full of crap. Your only intent is to find
any lame excuse to stalk, harass and troll, Frank.
Gerard Lanois
I thought _ was pretty wacky the first time I ran across it.
See perldoc -f stat for details.
-Gerard
Brian McCauley
> Brian McCauley wrote:
>
> > Godzilla! wrote:
[ something relatively sensible ]
> > I'm actually inclined to agree.
>
> You are full of crap.
I was worried when I agreed with two things that Godzilla said in one
day. Good to see you are back on the usual form. Actually you have
surpassed yourself, you usually only tell people[1] that they are full
of crap then they disagree with you.
> Your only intent is to find any lame excuse to stalk, harass and
> troll, Frank.
And thankyou for calling me "Frank". It helps to ensure that everyone
will recoginise your paranoid rantings for what they are and avoid
anyone taking your slander seriously.
[1] Sorry, did I say "people" - surely I meant "Frank", after all,
there is, in your reality, only one person who objects to your
trolling and that's Frank.
Cameron Dorey
>
> "Godzilla!" <godz...@stomp.stomp.tokyo> writes:
>
> > Your only intent is to find any lame excuse to stalk, harass and
> > troll, Frank.
>
> And thankyou for calling me "Frank". It helps to ensure that everyone
> will recoginise your paranoid rantings for what they are and avoid
> anyone taking your slander seriously.
>
> [1] Sorry, did I say "people" - surely I meant "Frank", after all,
> there is, in your reality, only one person who objects to your
> trolling and that's Frank.
Actually, I don't know if Frank objects to G's trolling, or if he sees
it, or if he even has a computer/terminal/cell phone/whatever, because I
have never seen him respond to any of these accusations. As far as I can
tell, Godzilla has a personal beef with the French monetary system.
Maybe someone exchanged francs for USD for her straight up once ...
Cameron
--
Cameron Dorey
Associate Professor of Chemistry
University of Central Arkansas
Phone: 501-450-5938
came...@mail.uca.edu
Tintin
"Graham W. Boyes - HawHawJokes.com"
message news:sfaE8.15970$27.5...@news2.telusplanet.net...
> Thus quoth Ross Clement:
> > What feature of perl (syntax or built in function) is the most
obscure/least
> > intuitive? By this, I mean a basic, common, feature of the language, not
> > a library or mmodule.
>
>
> How about the part that makes it go "Premature End of Script
Headers"......
> Graham
Perl has no such error message. You are getting Perl and CGI confused.
Garry Knight
> What feature of perl (syntax or built in function) is the most
> obscure/least intuitive?
The bits I haven't learnt yet. :o)
--
Garry Knight
garry...@gmx.net ICQ 126351135
Linux registered user 182025
Benjamin Goldberg
There are a number of candidates...
The fact that $& and friends slow down *all* regex matches.
I think that list/scalar context is unintuitive for newbies... nothing
like it exists in any other language.
The behavior of subs within subs, with respect to lexicals declared in
the outer sub and used in the inner sub.
The fact that local applies to values, not variables.
Certain constructs (for, foreach) alias $_. If some of those elements
have tie magic, local $_ will FETCH() the old value, STORE() the new,
and later on re-STORE() the earlier FETCH()ed value. Sometimes this is
what you want, sometimes not. local *_ breaks the aliasing, but it also
hides @_.
--
print reverse( ",rekcah", " lreP", " rehtona", " tsuJ" )."\n";
Martien Verbruggen
If you hadn't qualified it like that, I would have answered "Damian
Conway".
;)
Martien
--
|
Martien Verbruggen |
Trading Post Australia | The gene pool could use a little chlorine.
|
Eric J. Roode
Hash: SHA1
cle...@westminster.ac.uk (Ross Clement) wrote in
news:3ce12ff0$1...@isls-news.wmin.ac.uk:
Most obscure? I'd have to say ?...?. I don't believe I've ever seen it in
a real world program, in my seven years of Perl programming.
- --
@_=unpack "C*",qq;\cw22(D\coF?!%\$&D\x1e=B\cyB'\cu"\cy=B\; $>=0; ;$=-=$=;
push (@^A,$_[$=++]+$_),$^A[$=-1]=~s+\d[^$0.=^$1].+$&-ord e+e
foreach map{unpack 'C'x8,$_}(\getpwuid $>)[0,2,5];
print pack('C*',@^A),"\n";
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPOGn2mPeouIeTNHoEQJ3igCg490bvsEIJ/RhRXJspNpwpnRmF/0An2g7
dSp9mgoOl11/l2GmG4AEs9qe
=fFNH
-----END PGP SIGNATURE-----
Randal L. Schwartz
Eric> Most obscure? I'd have to say ?...?. I don't believe I've ever
Eric> seen it in a real world program, in my seven years of Perl
Eric> programming.
Well, heading down that road, what about "reset" resetting that
once-only match? I don't think I've *ever* seen that used except in
an example.
And the general "reset a-z" thing really sorta went out of favor
somewhere in the early 90s. :)
print "Just another Perl hacker," if reset;
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Helgi Briem
<sp...@all.costs.must.die> wrote:
>> How about the part that makes it go "Premature End of Script
>Headers"......
>Perl has no such error message. You are getting Perl and CGI confused.
>
For god's sake. The man was joking.
--
Regards, Helgi Briem
helgi AT decode DOT is
Matt Sergeant
$^H/%^H, without a doubt.
Matt.
Anno Siegel
> On Tue, 14 May 2002 22:01:00 GMT, "Tintin"
> <sp...@all.costs.must.die> wrote:
>
> >> How about the part that makes it go "Premature End of Script
> >Headers"......
>
> >Perl has no such error message. You are getting Perl and CGI confused.
> >
> For god's sake. The man was joking.
...more specifically, he was trolling. At least, that's what the
word used to mean on Usenet before it came to mean any disruptive
posting.
A troll, to elaborate a little on this bit of Usenet etymology, used
to be the property of a posting, not a poster, and it had nothing to
do with the guy under the bridge, but with fishing. You posted an
egregious falsehood with a straight face (well, typeface, to stay
with the theme of Usenet). Then you waited for people to elaborately
explain how wrong you are. These were your catches, though catching
a newbie didn't count much. For a good troll you needed a regular of
good standing to bite, the more of them the merrier.
This is how "trolling" was used when it came up on AFU almost a
decade ago. The word has changed its meaning quite a bit, and
while it's interesting to watch etymology in action at this pace,
there is the reaction of Old Farts all around the world: "This isn't
what it used to mean, and I don't have to like it".
So, good catch, Mr. sp...@all.costs.must.die :)
Anno
Ross Clement
: cle...@westminster.ac.uk (Ross Clement) wrote in message news:<3ce12ff0$1...@isls-news.wmin.ac.uk>...
What does that do?
Cheers,
Ross-c
Bernard El-Hagin
perldoc perlvar
Cheers,
Bernard
--
echo 42|perl -pe '$#="Just another Perl hacker,"'
Anno Siegel
...right there with the higher return values of caller.
Anno
Lou Moran
<godz...@stomp.stomp.tokyo> wrote a glowing report about my Usenet
practices:
>You are full of crap. Your only intent is to find
>any lame excuse to stalk, harass and troll, Frank.
>
>
>Godzilla!
I think a large section of a book I am writing will be done in usenet
posts... I think I have found my comic relief.
You are completely insane, but very funny... In a scary clown sort of
way.
--
Lou Moran
(P3 850)
Guinness _has_ affected this post
Steffen Müller
news:abtr2g$rlf$1...@mamenchi.zrz.TU-Berlin.DE...
Straight from the docs:
for the frame. "$hints" and "$bitmask" contain pragmatic hints
that the caller was compiled with. The "$hints" and "$bitmask"
values are subject to change between versions of Perl, and are
not meant for external use.
[...]
To be honest, this bit of documentation tells me exactly nothing about
$hints and $bitmask except that I should better stay away from it until I
happen to swallow the source code. The rest of the higher return values
seemed obvious and even useful if it wasn't for
Be aware that the optimizer might have optimized call frames
away before "caller" had a chance to get the information. That
means that "caller(N)" might not return information about the
call frame you expect it do, for "N > 1".
[...]
which makes them pretty useless for any of my purposes.
By the way, there's a type in there: s/\bdo/to/
Henry McGuinness
>What does that do?
Exactly!
Benjamin Goldberg
> Anno Siegel wrote:
> | Matt Sergeant wrote:
> | > Ross Clement wrote:
> | > > Hi. Another challenge for y'all.
> | > >
> | > > What feature of perl (syntax or built in function) is the most
> | > > obscure/least intuitive? By this, I mean a basic, common,
> | > > feature of the language, not a library or mmodule.
> | >
> | > $^H/%^H, without a doubt.
> |
> | ...right there with the higher return values of caller.
>
> Straight from the docs:
>
> for the frame. "$hints" and "$bitmask" contain pragmatic hints
> that the caller was compiled with. The "$hints" and "$bitmask"
> values are subject to change between versions of Perl, and are
> not meant for external use.
> [...]
>
> To be honest, this bit of documentation tells me exactly nothing about
> $hints and $bitmask except that I should better stay away from it
> until I happen to swallow the source code.
$hints and $bitmask are the caller's values of $^H and ${^WARNING_BITS}.
> The rest of the higher return values
> seemed obvious and even useful if it wasn't for
>
> Be aware that the optimizer might have optimized call frames
> away before "caller" had a chance to get the information. That
> means that "caller(N)" might not return information about the
> call frame you expect it do, for "N > 1".
> [...]
>
> which makes them pretty useless for any of my purposes.
I'm not aware of any occasion where anything like this happens, except
when one does goto &subname.
Could somebody enlighten me?
> By the way, there's a type in there: s/\bdo/to/
--
Anno Siegel
> Steffen Müller wrote:
> > The rest of the higher return values
> > seemed obvious and even useful if it wasn't for
> >
> > Be aware that the optimizer might have optimized call frames
> > away before "caller" had a chance to get the information. That
> > means that "caller(N)" might not return information about the
> > call frame you expect it do, for "N > 1".
> > [...]
> >
> > which makes them pretty useless for any of my purposes.
>
> I'm not aware of any occasion where anything like this happens, except
> when one does goto &subname.
>
> Could somebody enlighten me?
Not really, except to remark that the "goto &" case doesn't seem to be
what the remark is about. It is well documented that the current stack
frame is re-used with "goto &", and this is hardly an optimizer issue.
Also, "goto &" influences caller(N) for N=0.
If an optimizer were to replace sub calls with gotos, as in tail-recursion
optimization the remark would make more sense, but AFAIK current Perl
doesn't do that.
Anno
Philip Newton
wrote:
> What feature of perl (syntax or built in function) is the most obscure/least
> intuitive?
.. and ... in scalar context, especially when the operands are neither
numbers nor regular expressions?
Cheers,
Philip
--
Philip Newton <nospam...@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.
Brian McCauley
> What feature of perl (syntax or built in function) is the most obscure/least
> intuitive? By this, I mean a basic, common, feature of the language, not
> a library or mmodule.
Another candiate, the way \ distrbutes over lexical lists.
@r = \(@a); # $r[0] is reference to $a[0], $r[1] to $a[1] etc.
@r = \(@a,@b); # $r[0] is reference to @a, $r[1] to @b
Josef Drexler
> cle...@westminster.ac.uk (Ross Clement) writes:
>
>> What feature of perl (syntax or built in function) is the most obscure/least
>> intuitive? By this, I mean a basic, common, feature of the language, not
>> a library or mmodule.
>
> Another candiate, the way \ distrbutes over lexical lists.
>
> @r = \(@a); # $r[0] is reference to $a[0], $r[1] to $a[1] etc.
So far that's understandable if a bit obscure.
> @r = \(@a,@b); # $r[0] is reference to @a, $r[1] to @b
But this is really obscure! It's against the rule that all lexical lists
are flattened. Apparently that rule doesn't apply to reference-taking
lists. Wow, you do learn something new every day...
--
Josef Drexler | http://publish.uwo.ca/~jdrexler/
---------------------------------+----------------------------------------
Please help Conserve Gravity | Email address is *valid*.
Stop flipping pancakes. | Don't remove the "nospam" part.
Aristoteles Pagaltzis
> I think that list/scalar context is unintuitive for newbies... nothing
> like it exists in any other language.
But it is, along with undef, what makes Perl so concise.
Regards,
Aristotle
Aristoteles Pagaltzis
Incredibly obvious once you grok Perl, but it traps newbies all the
time: lenght(@array)
Godzilla!
> Ross Clement wrote:
> Incredibly obvious once you grok Perl, but it traps newbies all the
> time: lenght(@array)
This also annoys English professors significantly.
Godzilla!
--
Roberta The Remarkable Robot, Mistress Of Mind Munching!
http://la.znet.com/~callgirl/roberta/roberta.cgi
Chahta Chat, The Most Entertaining Chat To Be Found!
http://la.znet.com/~callgirl/webchat/chahta.cgi
Philip Newton
wrote:
> Incredibly obvious once you grok Perl, but it traps newbies all the
> time: lenght(@array)
And will be "fixed" in Perl 6, as I understand it.
Benjamin Goldberg
> Benjamin Goldberg wrote:
>
> > I think that list/scalar context is unintuitive for newbies...
> > nothing like it exists in any other language.
>
> But it is, along with undef, what makes Perl so concise.
In trying to think of what other languages have things like undef, it
occurs to me that Lisp has something that's sorta like a list-context:
multiple-value-bind to pull apart a list of returned values, and values
to return such a list. It also has NIL which acts as a kind of undef.