[32365] in Perl-Users-Digest
Perl-Users Digest, Issue: 3632 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 6 21:09:26 2012
Date: Tue, 6 Mar 2012 18:09:09 -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 Tue, 6 Mar 2012 Volume: 11 Number: 3632
Today's topics:
Re: $var = do { ... }? <rweikusat@mssgmbh.com>
Re: $var = do { ... }? <ben@morrow.me.uk>
Re: $var = do { ... }? <rweikusat@mssgmbh.com>
Re: access to variable names inside subprocedure <rvtol+usenet@xs4all.nl>
Re: access to variable names inside subprocedure <cartercc@gmail.com>
Re: access to variable names inside subprocedure <cwilbur@chromatico.net>
Re: access to variable names inside subprocedure <kiuhnm03.4t.yahoo.it>
Re: little quiz <ben@morrow.me.uk>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz <ben@morrow.me.uk>
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: little quiz (Seymour J.)
Re: little quiz <kiuhnm03.4t.yahoo.it>
Re: references (4567890) <rvtol+usenet@xs4all.nl>
Re: references (4567890) (Tim McDaniel)
Re: references (4567890) <kiuhnm03.4t.yahoo.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 05 Mar 2012 15:22:36 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: $var = do { ... }?
Message-Id: <87r4x7kr7n.fsf@sapphire.mobileactivedefense.com>
"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
> On 2012-03-02 21:10, Ben Morrow wrote:
>> If you insist on doing the eval yourself, you should test the truth of
>> the eval
>>
>> eval {
>> ...
>> } or do {
>> ...
>> };
>>
>> rather than relying on $@, since there are cases (destructors, for one,
>> depending on your version of perl) where $@ can be cleared even though
>> the eval failed. You still lose the error, but at least you know there
>> was one.
>
> Indeed, testing $@ is a bad practice.
>
> Your code snippet is missing some important features, see:
>
> my $ok;
> eval {
> $ok = foo();
> 1; # success
> }
> or do { # exception
> my $eval_error = $@ || 'zombie error';
> ...;
> };
But this does nothing but 'test $@' in order to determine if an error
occurred. There's just an additional bit of useless code wrapped
around it which is based on the (unjustified) assumption that the
value returned by the last thing evaluated inside the eval will never
be 0, '' or undef. Essentially, this amounts abandoning the concept of
using 'exceptions' for out-of-band error signalling and going back to
implicit 'special return value' conventions instead while retaining all
the run-time overhead of the exception mechanism. This can be achieved
in a much clearer way by simply not using exceptions and maybe arguing
in public that anything but using special return-value conventions for
error signalling would be 'bad practice' (because of ...)
OTOH, "that's your opinion" and some people don't agree with that,
cf
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl
Now, where's the 'foaming mouth guy' crying "This is deprecated !
Deprected !! Deprecated !!! Die, sinner, die !!!!"?
Can't you just accept that your vision for Perl is by no means
universal and that people use Perl in many different ways, no matter
if J. Random Multicolor Loser who wasn't asked for his insignificant
opinion to begin with approves of that?
Go Python, "there's only my way or the highway" guy. That's where you
belong to.
------------------------------
Date: Mon, 5 Mar 2012 16:38:19 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: $var = do { ... }?
Message-Id: <ro6f29-dsv1.ln1@anubis.morrow.me.uk>
Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> On 2012-03-02 21:10, Ben Morrow wrote:
>
> > If you insist on doing the eval yourself, you should test the truth of
> > the eval
> >
> > eval {
> > ...
> > } or do {
> > ...
> > };
> >
> > rather than relying on $@, since there are cases (destructors, for one,
> > depending on your version of perl) where $@ can be cleared even though
> > the eval failed. You still lose the error, but at least you know there
> > was one.
>
> Indeed, testing $@ is a bad practice.
>
> Your code snippet is missing some important features, see:
>
> my $ok;
> eval {
> $ok = foo();
> 1; # success
> }
> or do { # exception
> my $eval_error = $@ || 'zombie error';
> ...;
> };
That was part of the '...' :).
But yes, making sure the return value of the eval is what you expect is
important.
Ben
------------------------------
Date: Mon, 05 Mar 2012 20:50:00 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: $var = do { ... }?
Message-Id: <87d38qai2v.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> Localising $@ in DESTROY would not be sufficient, even if you could rely
[...]
>> See the BACKGROUND section of Try::Tiny's documentation.
>
> Hic Rhodos, hic salta: What are you precisely referring to? I read
> this background section and wrote about the two things I found in
> there which were not just handwaiving. So, what did I miss and/or get
> wrong?
Since (somewhat expectedly) nothing came of that and I've re-read the
Try::Tiny BACKGROUND section meanwhile with more attention to detail,
I now confidently state that the 'Localizing ... would not be
sufficient' statement is wrong. Adressing each of the 'rationales' in
turn:
,----
| Clobbering $@
|
| When you run an eval block and it succeeds, $@ will be
| cleared, potentially clobbering an error that is currently
| being caught.
|
| [...]
|
| $@ must be properly localized before invoking eval in order to avoid
| this issue.
`----
As I already wrote: This is the documented behaviour of eval and it is
the responsibility of the code which is interested in the content of
$@ to store that in some safe place before invoking other code which
might cause the value of $@ to be changed. That's a side effect of the
design descision to use a global variable to store the most recently
thrown exception. Taking this into account, this design descision can
certainly be called 'somewhat unfortunate', however, this is argueing
about spilt milk: perl behaves in the way it does and application
code written in Perl needs to take this into account. It is in no way
sensible to burden code which is regularly executed with working
around possible errors in the calling code, as suggested in the '$@
must be properly localized'.
,----
| Localizing $@ silently masks errors
|
| Inside an eval block die behaves sort of like:
|
| sub die {
| $@ = $_[0];
| return_undef_from_eval();
| }
|
| This means that if you were polite and localized $@ you can't die in
| that scope, or your error will be discarded (printing "Something's
| wrong" instead).
`----
... not only is the idea to always localize $@ 'just in case' before
executing eval not sensible, it additionally breaks exception
propagation out of the current lexical scope. But since it is only
necessary to work around this problematic side effect when proactively
trying to work around the non-problem described in the previous
paragraph, this is not generally an issue.
,----
| $@ might not be a true value
|
| This code is wrong:
|
| if ( $@ ) {
| ...
| }
|
| because due to the previous caveats it may have been unset.
`----
But there were no such 'previous caveats', just a remark about the
documented behaviour of eval and how that may interact badly with some
calling code written based on the wrong assumption that $@ would not
be a global variable. Actually, $@ can't be 'unset' except as side
effect of code which runs between the time of the original die and the
time the caller looks at $@. Minus the already mentioned 'caller bug'
of not saving $@, this leaves a single possible problem situation,
namely,
,----
| The classic failure mode is:
|
| sub Object::DESTROY {
| eval { ... }
| }
|
| eval {
| my $obj = Object->new;
|
| die "foo";
| };
|
| if ( $@ ) {
|
| }
`----
This is an actual problem because destructors can be executed after a
die and before the caller of the eval ever gets a chance to look at
$@. As I already wrote, because of this, a destructor which doesn't
localize $@ if it already has a value before executing code which
might either eval or die is broken. It is possible that the value in
$@ isn't interesting to the (indirect) caller anymore and that the
destructor just sees it because $@ is a global variable, but there's
no way to distinguish between these two cases.
Lastly,
,----
| The workaround for this is even uglier than the previous ones. Even
| though we can't save the value of $@ from code that doesn't localize,
| we can at least be sure the eval was aborted due to an error:
|
|
| my $failed = not eval {
| ...
|
| return 1;
| };
`----
there's little point in disabling useful features (out-of-band error
signalling, eval return values) in order to work around hypothetical
bugs in destructors. Instead, the buggy destructors need to be fixed.
------------------------------
Date: Mon, 05 Mar 2012 13:17:17 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: access to variable names inside subprocedure
Message-Id: <4f54aecd$0$6928$e4fe514c@news2.news.xs4all.nl>
On 2012-03-05 11:54, Kiuhnm wrote:
> Another thing: try Haskell instead. It's much less lispy.
But check out clojure too. Successful example: cascalog.
--
Ruud
------------------------------
Date: Mon, 5 Mar 2012 06:32:17 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <cf0ecaf6-e729-4616-8c1e-bf3909d36278@p6g2000yqi.googlegroups.com>
On Mar 5, 7:17=A0am, "Dr.Ruud" <rvtol+use...@xs4all.nl> wrote:
> On 2012-03-05 11:54, Kiuhnm wrote:
>
> > Another thing: try Haskell instead. It's much less lispy.
>
> But check out clojure too. Successful example: cascalog.
>
> --
> Ruud
I have looked at Clojure, Haskell, and (more than just a look) Prolog.
I divide languages into three kinds: those you need to get your work
done, those you would like to study for some particular reason, and
'hobby' languages -- those you would like to study for no particular
reason.
In the first group, I have quite a list, Perl, Java, JavaScript, SQL,
and so on. It's pretty much all I can do to keep these in mind enough
to use them.
In the second group, I would include R (generating graphics),
Objective-C (mobile apps), PowerShell, and several others.
In the third group, I would include Lisp and Erlang.
Unfortunately, the more time you spend with the first group, the less
time you have to spend with the others. And vice versa.
Still, I fully agree with the guy who said (Eric Raymond? Richard
Stallman?) that you should learn one new language every year. I find
that the idioms of different languages can be profitably applied with
your workhorse language.
CC.
------------------------------
Date: Tue, 06 Mar 2012 13:01:09 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: access to variable names inside subprocedure
Message-Id: <87fwdlr4m2.fsf@new.chromatico.net>
>>>>> "KKiuhnm" == Kiuhnm <kiuhnm03.4t.yahoo.it> writes:
KKiuhnm> You should read the book "Concepts, Techniques, and Models
KKiuhnm> of Computer Programming".
Or possibly _The Structure and Interpretation of Computer Programs_.
When I was an undergraduate, the requirement for a course in writing
compilers was under heavy attack because, hey, everyone knew that
Borland and Microsoft had the market cornered and who really needs to
write a compiler from scratch? Way to miss the point, guys.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 07 Mar 2012 01:17:32 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: access to variable names inside subprocedure
Message-Id: <4f56a91b$0$1380$4fafbaef@reader2.news.tin.it>
On 3/6/2012 19:01, Charlton Wilbur wrote:
>>>>>> "KKiuhnm" == Kiuhnm<kiuhnm03.4t.yahoo.it> writes:
>
> KKiuhnm> You should read the book "Concepts, Techniques, and Models
> KKiuhnm> of Computer Programming".
>
> Or possibly _The Structure and Interpretation of Computer Programs_.
>
> When I was an undergraduate, the requirement for a course in writing
> compilers was under heavy attack because, hey, everyone knew that
> Borland and Microsoft had the market cornered and who really needs to
> write a compiler from scratch? Way to miss the point, guys.
SICP and CTMCP are two different beasts. I'd recommend both of them.
CTMCP introduces the reader to a multi-paradigm language named "Oz".
Kiuhnm
------------------------------
Date: Mon, 5 Mar 2012 16:50:13 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: little quiz
Message-Id: <5f7f29-dsv1.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> On 3/5/2012 0:39, Ben Morrow wrote:
> > Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
> [...]
> >> Same thing without the warning:
> >>
> >> sub f1 {
> >> my $v if my $y;
> >> ++$v;
> >> say $v;
> >> }
> >
> > I think the lack of warning is not intentional: that is, I think any
> > change to core perl which caused my example to stop working would do the
> > same to yours, it's just not so visible at compile time that that is the
> > case.
>
> Much in Perl is not intentional :)
> Do you remember my post about given...when?
> Perl's syntax is so complex that suprises are bound to come up.
Yup. If you want Scheme, you know where to find it :).
> >> I didn't even know that
> >> my $v = 7;
> >> my $v = 0;
> >> was possible.
<snip>
> >> I didn't know that "my" was an operator.
> >
> > I'm not sure what you mean by that... it has a runtime effect,
> > certainly.
>
> In many languages, those are just directives to the compiler. Their
> effect is entirely determined at compile-time.
perl (5) doesn't allocate a new lexical pad for each iteration of a
block, instead each 'my' registers a destructor on the scope which will
clear the variable out or replace it if it's still got refs. This is
done solely as an efficiency measure, though it does have a few
Perl-visible side effects (as we've discussed before).
Over and above that, Perl will allow you to declare a variable which
masks another of the same name in the same scope, which some languages
won't. (Though it will give you a warning.) I think this is mostly a
consequence of not keeping the compile-time lexical structure at
runtime, which means that the pad already has to be able to handle
having two variables called '$v' scoped over a slightly different set of
statements.
> > Those two things go together: the sub definition is only evaluated once
> > *because* you're defining a globally-visible named sub. What you were
> > expecting is 'my sub', which doesn't exist yet (and very possibly never
> > will: it seems it's harder to get right than it appears).
> >
> > It's no worse, really, than sub definitions being visible outside the
> > file they were defined in. They are global objects living in the symbol
> > table, so their names aren't lexically scoped at all (modulo tricks like
> > namespace::clean...).
>
> Will Perl 6 correct these issues? I understand it will break code anyway.
Having global subs is a feature, not a bug. Having *only* global subs is
a bug; AIUI Perl 6 has proper lexically-scoped named subs.
Ben
------------------------------
Date: Mon, 05 Mar 2012 19:18:21 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f55036b$0$1393$4fafbaef@reader1.news.tin.it>
On 3/5/2012 17:50, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> On 3/5/2012 0:39, Ben Morrow wrote:
>>> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> [...]
>>>> Same thing without the warning:
>>>>
>>>> sub f1 {
>>>> my $v if my $y;
>>>> ++$v;
>>>> say $v;
>>>> }
>>>
>>> I think the lack of warning is not intentional: that is, I think any
>>> change to core perl which caused my example to stop working would do the
>>> same to yours, it's just not so visible at compile time that that is the
>>> case.
>>
>> Much in Perl is not intentional :)
>> Do you remember my post about given...when?
>> Perl's syntax is so complex that suprises are bound to come up.
>
> Yup. If you want Scheme, you know where to find it :).
One of the few languages with a 50-page spec!
>>>> I didn't even know that
>>>> my $v = 7;
>>>> my $v = 0;
>>>> was possible.
> <snip>
>>>> I didn't know that "my" was an operator.
>>>
>>> I'm not sure what you mean by that... it has a runtime effect,
>>> certainly.
>>
>> In many languages, those are just directives to the compiler. Their
>> effect is entirely determined at compile-time.
>
> perl (5) doesn't allocate a new lexical pad for each iteration of a
> block, instead each 'my' registers a destructor on the scope which will
> clear the variable out or replace it if it's still got refs. This is
> done solely as an efficiency measure, though it does have a few
> Perl-visible side effects (as we've discussed before).
>
> Over and above that, Perl will allow you to declare a variable which
> masks another of the same name in the same scope, which some languages
> won't. (Though it will give you a warning.) I think this is mostly a
> consequence of not keeping the compile-time lexical structure at
> runtime, which means that the pad already has to be able to handle
> having two variables called '$v' scoped over a slightly different set of
> statements.
>
>>> Those two things go together: the sub definition is only evaluated once
>>> *because* you're defining a globally-visible named sub. What you were
>>> expecting is 'my sub', which doesn't exist yet (and very possibly never
>>> will: it seems it's harder to get right than it appears).
>>>
>>> It's no worse, really, than sub definitions being visible outside the
>>> file they were defined in. They are global objects living in the symbol
>>> table, so their names aren't lexically scoped at all (modulo tricks like
>>> namespace::clean...).
>>
>> Will Perl 6 correct these issues? I understand it will break code anyway.
>
> Having global subs is a feature, not a bug. Having *only* global subs is
> a bug; AIUI Perl 6 has proper lexically-scoped named subs.
But named sub are always global. Why should I use a coderef just to make
a sub non-global?
Kiuhnm
------------------------------
Date: Mon, 5 Mar 2012 22:40:09 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: little quiz
Message-Id: <9vrf29-q742.ln1@anubis.morrow.me.uk>
Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> On 3/5/2012 17:50, Ben Morrow wrote:
> > Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
> >>
> >> Will Perl 6 correct these issues? I understand it will break code anyway.
> >
> > Having global subs is a feature, not a bug. Having *only* global subs is
> > a bug; AIUI Perl 6 has proper lexically-scoped named subs.
>
> But named sub are always global. Why should I use a coderef just to make
> a sub non-global?
Because (and only because) noone's written the bits of code to make 'my
sub' work yet. There are maybe three or four people in the world who
understand all the subtleties of perl's lexical pads well enough to
implement something like this; IIRC the last time one of them (Dave
Mitchell) looked at the problem he said it was more complicated than it
appeared.
*However*, there are some neat tricks you can do with the symbol table,
if you're willing to get your hands a bit dirty:
package Foo;
no strict; # obviously this would be scoped in practice
use B::Hooks::EndOfScope;
sub import {
my $pkg = caller;
*{"$pkg\::foo"} = sub { "foo" };
on_scope_end {
my $old = *{"$pkg\::foo"};
my $stash = \%{"$pkg::"};
delete $stash->{foo};
# this will autoviv a new glob
my $new = *{"$pkg\::foo"};
*$old{SCALAR} and *$new = *$old{SCALAR};
*$old{ARRAY} and *$new = *$old{ARRAY};
*$old{HASH} and *$new = *$old{HASH};
*$old{IO} and *$new = *$old{IO};
# skip FORMAT since it's buggy in some perls
};
}
Now, when you say
{
use Foo;
say foo;
}
say foo;
the first call to foo calls the installed sub, but the second gives you
an undefined sub error. Also, if you say
use Foo;
say foo;
say main->foo;
the sub call calls the installed sub, but the method call gives an
undefined method error.
This was (as usual) quite accidental, but is extremely useful. It
happens because perl resolves sub calls as far as the relevant glob at
compile time, so if you replace that glob in the symbol table you can
put a different sub (or no sub at all) in its place without affecting
already-compiled code.
(The reason perl only resolves as far as the glob, and not right down to
the CV, is to allow subs to be redefined. So a simple
undef &{"$pkg\::foo"};
or
*{"$pkg\::foo"} = sub { "bar" };
*would* affect the already-compiled code, since it leaves the same glob
in the stash and only affects its CV entry.)
This idea is what is behind namespace::clean and the other namespace::*
modules, which hide the nasty internals behind a cleaner interface.
Ben
------------------------------
Date: Tue, 06 Mar 2012 12:25:26 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f55f425$0$1378$4fafbaef@reader2.news.tin.it>
On 3/5/2012 23:40, Ben Morrow wrote:
> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> On 3/5/2012 17:50, Ben Morrow wrote:
>>> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>>>>
>>>> Will Perl 6 correct these issues? I understand it will break code anyway.
>>>
>>> Having global subs is a feature, not a bug. Having *only* global subs is
>>> a bug; AIUI Perl 6 has proper lexically-scoped named subs.
>>
>> But named sub are always global. Why should I use a coderef just to make
>> a sub non-global?
>
> Because (and only because) noone's written the bits of code to make 'my
> sub' work yet. There are maybe three or four people in the world who
> understand all the subtleties of perl's lexical pads well enough to
> implement something like this; IIRC the last time one of them (Dave
> Mitchell) looked at the problem he said it was more complicated than it
> appeared.
>
> *However*, there are some neat tricks you can do with the symbol table,
> if you're willing to get your hands a bit dirty:
>
> package Foo;
>
> no strict; # obviously this would be scoped in practice
> use B::Hooks::EndOfScope;
>
> sub import {
> my $pkg = caller;
>
> *{"$pkg\::foo"} = sub { "foo" };
>
> on_scope_end {
> my $old = *{"$pkg\::foo"};
> my $stash = \%{"$pkg::"};
>
> delete $stash->{foo};
> # this will autoviv a new glob
> my $new = *{"$pkg\::foo"};
>
> *$old{SCALAR} and *$new = *$old{SCALAR};
> *$old{ARRAY} and *$new = *$old{ARRAY};
> *$old{HASH} and *$new = *$old{HASH};
> *$old{IO} and *$new = *$old{IO};
> # skip FORMAT since it's buggy in some perls
> };
> }
>
> Now, when you say
>
> {
> use Foo;
> say foo;
> }
> say foo;
>
> the first call to foo calls the installed sub, but the second gives you
> an undefined sub error. Also, if you say
>
> use Foo;
> say foo;
> say main->foo;
>
> the sub call calls the installed sub, but the method call gives an
> undefined method error.
>
> This was (as usual) quite accidental, but is extremely useful. It
> happens because perl resolves sub calls as far as the relevant glob at
> compile time, so if you replace that glob in the symbol table you can
> put a different sub (or no sub at all) in its place without affecting
> already-compiled code.
>
> (The reason perl only resolves as far as the glob, and not right down to
> the CV, is to allow subs to be redefined. So a simple
>
> undef&{"$pkg\::foo"};
> or
> *{"$pkg\::foo"} = sub { "bar" };
>
> *would* affect the already-compiled code, since it leaves the same glob
> in the stash and only affects its CV entry.)
>
> This idea is what is behind namespace::clean and the other namespace::*
> modules, which hide the nasty internals behind a cleaner interface.
I'm sure you can do that kinds of things with some C compilers as well.
Just find an appropriate vulnerability and then inject some code in the
compiler using your source code as a vector...
Kiuhnm
------------------------------
Date: Tue, 06 Mar 2012 09:10:20 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: little quiz
Message-Id: <4f561acc$13$fuzhry+tra$mr2ice@news.patriot.net>
In <4f55036b$0$1393$4fafbaef@reader1.news.tin.it>, on 03/05/2012
at 07:18 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:
>But named sub are always global.
In Perl; 5. That's not true of all languages, especially not those
descended from Algol 60.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 07 Mar 2012 01:14:02 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: little quiz
Message-Id: <4f56a849$0$1383$4fafbaef@reader2.news.tin.it>
On 3/6/2012 15:10, Shmuel (Seymour J.) Metz wrote:
> In<4f55036b$0$1393$4fafbaef@reader1.news.tin.it>, on 03/05/2012
> at 07:18 PM, Kiuhnm<kiuhnm03.4t.yahoo.it> said:
>
>> But named sub are always global.
>
> In Perl; 5. That's not true of all languages, especially not those
> descended from Algol 60.
It goes without saying that I was talking of Perl. For instance, a few
years ago I designed a(n academic) programming language where named sub
aren't global.
Kiuhnm
------------------------------
Date: Mon, 05 Mar 2012 13:04:26 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: references (4567890)
Message-Id: <4f54abca$0$6928$e4fe514c@news2.news.xs4all.nl>
On 2012-03-02 18:19, Tim McDaniel wrote:
> In fact, I did want a "ref slice" a few days ago. I had an array of
> refs and I wanted the ID key out of all of them. I wanted to do
> @arr->{ID}
> but Perl doesn't allow that; I had to code it more verbosely as
> map { $_->{ID} } @arr
>
Parallel arrays are bad, go for matrices.
--
Ruud
------------------------------
Date: Tue, 6 Mar 2012 17:49:20 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: references (4567890)
Message-Id: <jj5in0$dah$1@reader1.panix.com>
In article <4f54abca$0$6928$e4fe514c@news2.news.xs4all.nl>,
Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
>On 2012-03-02 18:19, Tim McDaniel wrote:
>
>> In fact, I did want a "ref slice" a few days ago. I had an array of
>> refs and I wanted the ID key out of all of them. I wanted to do
>> @arr->{ID}
>> but Perl doesn't allow that; I had to code it more verbosely as
>> map { $_->{ID} } @arr
>
>Parallel arrays are bad, go for matrices.
I'm not sure what you mean. For one thing, Perl doesn't have matrices
per se.
Also, I don't necessarily get to choose the data structures. In this
case, it was a SQL interface that returned a ref to an array, where
each array element was a ref to a hash of the form COLUMNNAME =>
VALUE. If I want some other representation, then I have to haul out
map, foreach, or whatever to restructure it.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 07 Mar 2012 01:21:07 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: references (4567890)
Message-Id: <4f56a9f1$0$1381$4fafbaef@reader2.news.tin.it>
On 3/6/2012 18:49, Tim McDaniel wrote:
> In article<4f54abca$0$6928$e4fe514c@news2.news.xs4all.nl>,
> Dr.Ruud<rvtol+usenet@xs4all.nl> wrote:
>> On 2012-03-02 18:19, Tim McDaniel wrote:
>>
>>> In fact, I did want a "ref slice" a few days ago. I had an array of
>>> refs and I wanted the ID key out of all of them. I wanted to do
>>> @arr->{ID}
>>> but Perl doesn't allow that; I had to code it more verbosely as
>>> map { $_->{ID} } @arr
>>
>> Parallel arrays are bad, go for matrices.
>
> I'm not sure what you mean. For one thing, Perl doesn't have matrices
> per se.
Maybe a single array where you do the math yourself to access its
cells... don't know.
Argh... two lines (now three). Let's wait for Dr. Ruud for a one-line
explanation :)
Kiuhnm
------------------------------
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 3632
***************************************
