Sweetest Accessor?

[Uri Guttman]

XC> In article <[email protected]>,

XC> Yes. I think we can hammer at this distinction all night long
XC> without letting any more light into the room. I've tried to make
XC> it abundantly clear that an alias is not, as Perl defines it, a
XC> ref(erence). However, Perl does implement param passing via
XC> call-by-reference, generally speaking. Otherwise, it would not be
XC> possible to do anything within a sub that could clobber a param
XC> within the calling context.

the light needs to be shown inside your head. no one else has a problem
with how perl handles sub args. so stop making claims that make no
sense.

XC> Somebody at this point might say that an evil demon might pass a param
XC> *value*, then look to see if $_[$i] had been changed and if so, go back
XC> and put the new value back in the old mailbox. I don't know anything
XC> about Perl internals but I'll bet a dollar to a doughnut that this is
XC> not the case. Rather, I'll bet that $_[$i] points directly to the
XC> mailbox itself. Please correct me if I'm wrong.

*boggle*

XC> At this, my chosen level of abstraction, there are only two ways to pass
XC> a param to a sub: call-by-reference or call-by-value. Perl does the
XC> former. Am I mistaken? If so, how?

you chosen level is wrong. you write perl code as if it was always call
by value. you pass refs if you want call by ref. sometimes you can use
the alias nature of @_ to do call by ref but that IS NOT THE COMMON
CASE. so drop it already and ignore that case. it doesn't matter to
almost all the perl code out there. a very very tiny fraction uses @_ as
a call by ref. and hopefully only by those who understand why it is
useful

XC> It is deliberate (on the part of the Perl maintainers) and it is all the
XC> time. When somebody writing code in Perl fails to understand this
XC> mechanism he may, by accident, screw up -- and if foolish, blame Perl,
XC> if wise, study and learn. When somebody who understands it makes
XC> deliberate use of it, he may thank Larry Wall, wisely, or compliment
XC> himself, foolishly.

no. most perl coders never see that nor will that. most coders are
taught to copy @_ to lexical vars and that is call by value. simple and
safe and proper.

XC> ... and so it is. It is crystal clear in my mind -- both that params are
XC> not automatically refs, as defined by Perl; and that @_ is a list of
XC> parameters that are passed by the mechanism of call-by-reference. One
XC> thing is not the other; I don't know how to make it any clearer. I've
XC> done my best and I'm sorry if I've still come up short.

no you have made it clear you understand the difference. what you have
not made clear is whether you understand that the alias nature of is NOT
IMPORTANT. no one calls perl a pass by ref lang. its common style is
pass by value. that is what matters not how it is implemented.

XC> May the heavens guide the poor man who stumbles onto this thread,
XC> thinking about passing a Perl ref as a param. It certainly can be done
XC> (and often is) and this has nothing to do with the alias nature of @_.

no. they will see our replies to you and realize that common perl is
pass by value.

XC> If you copy the value, that doesn't make the calling mechanism
XC> call-by-value. A language that implements parameter passing via
XC> call-by-value will not (by default) pass anything to the sub that will
XC> allow it to modify anything outside the sub (except, perhaps, global
XC> variables and a return value, neither of which are enabled by the
XC> parameter passing mechanism). That is:

if you code in a pass by value style which is the recommended and taught
style it is a pass by value language. you have obviously never used PL/I
or algol or lisp or other pass by ref langs but which were largely used
in a pass by value style.

XC> A language that implements pass-by-reference will print 47. That's all;
XC> there is no in-between. An alias is a high-level abstraction that
XC> encapsulates a reference -- not a Perl ref, not something that can be
XC> interpreted as a Perl ref or explicitly dereffed. An alias is implicitly
XC> dereffed when used.

not if you copy from the alias first as is always taught and commonly
done. that is what matter. language conventions are just as important as
syntax and implementation. no language lives alone. perl is a pass by
value language because that is the convention. period. end of
discussion. nothing you say matters about this.

XC> Let me say again (in case it helps) that my primary orientation is way
XC> down the ladder. When a sub invokes in most languages, it pops its
XC> params off the stack. Now, at the moment of the pop, that word popping
XC> off the stack is either the value that the calling routine had in "mind"
XC> when deciding to call the sub; or that popped word is a pointer into the
XC> heap or possibly another part of the stack, at which location the actual
XC> value is found. The first case is call-by-value; the second
XC> call-by-reference.

it doesn't matter what you think or how it is implemented. it is pass by
value by convention. rinse. repeat.

XC> I've read others of this gentleman's posts and while it's not clear to
XC> me whether he knows his stuff or not, he *seems* to me to lean rather
XC> hard into other posters who don't appear to speak his language, his way.
XC> Either way, I certainly don't want to insult him -- or anyone else. Yet
XC> I would appreciate being allowed the same courtesy and I'm afraid I'm
XC> not going to get it.

which gentleman?

XC> Am I right, in which case I should from now on ignore him? Or am I a
XC> babbling fool? I leave it to the group to set me straight.

you an ignore anyone you want. most will be ignoring you. few ignore me
or maybe more should. but i do know what call by value is and how perl
is a call by value language no matter how it is implemented
underneath. and i also said @_ is aliased for SPEED and RAM reasons but
copies are made of the args for SAFETY reasons. perl is both a floor wax
and a dessert topping.

uri

 

[Xiong Changnian]

Pardon the pedantry...

There's a group whose official motto is "too much pedantry is just
enough". I'll go so far as to say that there's little room for muddy
thinking in computer programming. But -- just to rock the boat -- one
reason for high-level languages is to allow the programmer a little
leeway. ("Do What You Want".)

One-shot for loops aren't that exotic in Perl.

No; I see them here and there and I've even implemented a switch/case
with such a thing. I'd like to think that when I do this, I *want* an
alias -- that's why I did it.

"for" (but not the non-word "foreach")

Say, are there two armed camps of Perl monks throwing gazillion megawatt
lightning bolts at one another over for/foreach? Reminds me of how to
liven up a Saturday night: Go to the gray-collar bar nearest the city
daily at shift change and shout "When should I use an en dash?"

I use foreach when iterating over a list and for when constructing a
traditional for loop. I know they're synonyms and that's cool.

It proves that what shift() returns *is* an lvalue and can be used to
clobber the actual parameter.

Well, I'm enlightened; thank you. I think I'd have to try pretty hard to
get stuck in that crack but it's always good to know what surprises
lurk.

I guess that shift() = 13 really "shouldn't" raise an exception, then.
Stuffy guys take away all the fun toys.

Perl's "postmodern", non-orthogonal design entails lots and lots of
edge cases where the actual behavior can't be derived from general
principles, but is geared to the particular case. It is often
distracting and sometimes impossible to discuss all that may be
relevant to a topic.

Um, well, at the risk of opening Pandora's Box, I'll say that I'm
extremely interested in all the edges, all the time. Perl's actual
design isn't all that's postmodern; so are the docs. I come from the
school where every last detail of operation is spelled out in the man,
one token per page. I can't quite quash the creeping suspicion that some
issues are glossed over in Perl docs because *nobody's* completely sure
what beautiful syntax the interpreter will accept. Besides, X might
change in a future implementation.

So, I really appreciate your willingness to dig out these edge
conditions and discuss them.

If I have one petty objection to Perl, it's that it tries so hard to Do
What I Want that some pretty crummy code still works, instead of holding
my idiocy up to the glaring light of fatal error. I'm an "all warnings,
all the time" guy, at least for now.

In my first few revisions of my learning project, I tested all the
params I shifted off and died if there weren't enough of them. I've
become a bit less paranoid now but it's hard to let go of formal params.
I think Perl may be the language that finally demands doc-as-you-go.

If I were to discuss all ramifications I'd have to mention the
possibility that the same parameter could appear a second time
in the argument list and the sub could still change that.

Well, okay, but from my point of view, that's not an issue.

sub foo {
my $this = shift;
$_[0] = 'Floyd';
my $that = $_[0];
$this . $that;
};

my $param = 'Larry';
my $return = foo ($param, $param);

.... will return 'LarryFloyd'. It doesn't matter which one's Pink. Yes,
$param got clobbered but I *did* that; it didn't "just happen".

I think we got onto this topic because I said I didn't generally care to
mix shift with $_[$i] -- I've done it but not as a daily thing. I prefer
to shift off onto my variables if I'm writing a big sub; if I'm going
for small and fast, I'll stick with @_.

If anything, the potential interactions between these two methods seem
to me to provide a foundation for my (frankly) instinctive tropism. I
can see how someone else might see it as entirely natural. I think it
makes most sense to mix-and-match when shifting off a few params for
processing "here", then passing the remaining @_ to another sub.

You mentioned that you like assigning in one fell swoop:

my ($A, $B, $C) = @_;

I don't, although it's more compact and I generally like compact. I much
prefer to put each "declaration" on a line by itself, perhaps with
comment. Maybe, after time passes, I'll take this particular thumb out
of my mouth.

 

[Xiong Changnian]

the light needs to be shown inside your head.

you chosen level is wrong.

if you code in a pass by value style which is the recommended and taught
style it is a pass by value language.

nothing you say matters about this.

it doesn't matter what you think or how it is implemented.

few ignore me or maybe more should.

Okay, I think my question's been answered. My apologies to Mr. Guttman.
I hope other members of this group will forgive me if somewhere down the
road, I repeat some other question that Mr. Guttman has already answered
for me, on the offchance that I've failed to read it.

 

[anno4000]

(e-mail address removed)-berlin.de wrote:
[...]

"for" (but not the non-word "foreach")

Say, are there two armed camps of Perl monks throwing gazillion megawatt
lightning bolts at one another over for/foreach? Reminds me of how to
liven up a Saturday night: Go to the gray-collar bar nearest the city
daily at shift change and shout "When should I use an en dash?"

Nothing of that sort. Use of for/foreach varies considerably among
Perl programmers, but it is rarely the subject of debate. The C-like
for (; is another matter. It is mostly avoided except for the
rare cases (arbitrary arithmetic sequences, for instance) where
it is clearly superior.

I use foreach when iterating over a list and for when constructing a
traditional for loop. I know they're synonyms and that's cool.

Theoretically I agree, in practice I find myself using "for" throughout.

Well, I'm enlightened; thank you. I think I'd have to try pretty hard to
get stuck in that crack but it's always good to know what surprises
lurk.

I guess that shift() = 13 really "shouldn't" raise an exception, then.
Stuffy guys take away all the fun toys.

I suppose it could technically be enabled if there was a sufficient
lobby, which isn't going to happen. The action on an arbitrary array
would verge on the bizarre: Shift it off and at the same time overwrite
it. It only makes sense if what is shifted is, in fact, an alias
to something else. The use in parameter passing is very limited,
in particular because changing the caller's arguments isn't a done
thing in Perl. No-one wants a syntax change to enable another way
to do that.

Um, well, at the risk of opening Pandora's Box, I'll say that I'm
extremely interested in all the edges, all the time. Perl's actual
design isn't all that's postmodern; so are the docs. I come from the
school where every last detail of operation is spelled out in the man,
one token per page. I can't quite quash the creeping suspicion that some
issues are glossed over in Perl docs because *nobody's* completely sure
what beautiful syntax the interpreter will accept. Besides, X might
change in a future implementation.

That is quite true. Perl doesn't have a formal description, and in
case of doubt the language definition is what the interpreter does.
The docs do a pretty good job of describing the mess and generally
make an effort not to gloss over murky points but to acknowledge
their existence. Perlre says, when describing the "(?{ code })"
construct:

Currently, the rules to determine where the "code" ends
are somewhat convoluted.

[...]

If I have one petty objection to Perl, it's that it tries so hard to Do
What I Want that some pretty crummy code still works, instead of holding
my idiocy up to the glaring light of fatal error.

Ah, the DWIMmer. It must be the bane of everyone trying to teach
Perl that it can be such a softie, forgiving errors that show
a fundamental misunderstanding in the programmers view of the
situation. It should crash and burn, instead it runs and may
even, in fact, to what was meant.

I'm an "all warnings, all the time" guy, at least for now.

Very good. You won't find reason to change that habit later.
I assume you also "use strict" habitually.

[...]

You mentioned that you like assigning in one fell swoop:

my ($A, $B, $C) = @_;

I don't, although it's more compact and I generally like compact. I much
prefer to put each "declaration" on a line by itself, perhaps with
comment. Maybe, after time passes, I'll take this particular thumb out
of my mouth.

There's a lot of variety. If arguments want individual initialization,
a sequence of shifts, combined with or followed by initialization is
probably better than assigning raw values compactly and then going back
to correct each one.

sub set_name {
my $obj = shift;
my $first = shift || 'John';
my $last = shift || 'Doe';
# ...
}

and not

sub set_name {
my ( $obj, $first, $last) = @_;
$first ||= 'John';
$last ||= 'Doe';
# ...

though the difference is small.

That doesn't even mention the popular style of named parameter passing.
It is mostly used when there are many parameters. Here the caller must
provide name-value pairs in the parameter list:

$obj->set_name( last => 'Curie', first => 'Marie');

In the sub, a hash is used to receive the pairs:

sub set_name {
my $obj = shift;
my %param = ( first => 'John', last => 'Doe', @_);
# ...

That provides the defaults nicely, but leaves you with a hash
of values instead of individual variables. Those require an
additional

my ( $first, $last) = @param{ qw( first last)};

There are many styles of receiving arguments. A common rule of
good style is to take the arguments from @_ early and not to
look back (at @_). Then again, occasionally a sub is busy with @_
throughout. There is no hard and fast rule. As often, Perl
leaves a lot to the implementor instead of defining it as part
of the language.

Anno

 

[Peter J. Holzer]

XC> In article <[email protected]>,


XC> Yes. I think we can hammer at this distinction all night long
XC> without letting any more light into the room. I've tried to make
XC> it abundantly clear that an alias is not, as Perl defines it, a
XC> ref(erence). However, Perl does implement param passing via
XC> call-by-reference, generally speaking. Otherwise, it would not be
XC> possible to do anything within a sub that could clobber a param
XC> within the calling context.

the light needs to be shown inside your head. no one else has a problem
with how perl handles sub args. so stop making claims that make no
sense.

The make sense to me (ok, maybe not in the first posting, but it got
clearer in the followups).

XC> Somebody at this point might say that an evil demon might pass a param
XC> *value*, then look to see if $_[$i] had been changed and if so, go back
XC> and put the new value back in the old mailbox. I don't know anything
XC> about Perl internals but I'll bet a dollar to a doughnut that this is
XC> not the case. Rather, I'll bet that $_[$i] points directly to the
XC> mailbox itself. Please correct me if I'm wrong.

*boggle*

Not much to boggle about. Xiong is is correct. The alternative he
describes is usually called "call-by-value-return" or sometimes "copy in
- copy out", but it isn't used by perl (at the moment I can't think of
any programming language (or implemention thereof) which uses this
mechanism - I know it only from the literature).

XC> At this, my chosen level of abstraction, there are only two ways to pass
XC> a param to a sub: call-by-reference or call-by-value. Perl does the
XC> former. Am I mistaken? If so, how?

you chosen level is wrong. you write perl code as if it was always call
by value.

I think you are talking at cross-purposes here. Xiong Changnian is
talking about how the parameter passing mechanism built into perl (@_)
works, and you are talking about a common idiom to build call-by-value
on top of that.

you pass refs if you want call by ref. sometimes you can use
the alias nature of @_ to do call by ref but that IS NOT THE COMMON
CASE. so drop it already and ignore that case. it doesn't matter to
almost all the perl code out there. a very very tiny fraction uses @_ as
a call by ref. and hopefully only by those who understand why it is
useful

How is somebody supposed to understand why it is useful if he gets
shouted at for asking questions about it?

XC> It is deliberate (on the part of the Perl maintainers) and it is all the
XC> time. When somebody writing code in Perl fails to understand this
XC> mechanism he may, by accident, screw up -- and if foolish, blame Perl,
XC> if wise, study and learn. When somebody who understands it makes
XC> deliberate use of it, he may thank Larry Wall, wisely, or compliment
XC> himself, foolishly.

no. most perl coders never see that nor will that. most coders are
taught to copy @_ to lexical vars and that is call by value. simple and
safe and proper.

Well, I wish someone had explained to me what the

my ($param, ...) = @_;

stuff was about. I simply cargo-culted it and found out that @_ is
call-by-reference the hard way - years after I started programming perl.

no you have made it clear you understand the difference. what you have
not made clear is whether you understand that the alias nature of is NOT
IMPORTANT. no one calls perl a pass by ref lang. its common style is
pass by value. that is what matters not how it is implemented.

I strongly disagree with that. Since it is "implemented" by the
programmer and not by perl, it is important. A perl programmer should
understand what he is writing.

hp