[mercury-users] Perl shift || $defalt

[Terrence Brannon]

Richard A. O'Keefe writes:
 > 
 > Terrence Brannon did not mention that
 >  - there is no notion of doing something if ARGV is *undefined*,
 >    but rather if it is *empty*, which is a different thing in Perl.

Pragmatically speaking, it would not make a difference in this case:

undef @ARGV; my $x = shift || 12; ### undefined array case
@ARGV = () ; my $x = shift || 12; ### empty     array case

# same result in both cases... $x == 12;

 >  - the array is *changed* as a side effect

I knew this and wanted to mention it, but decided to keep things simple.

 >  - in most uses, shift accesses and changes *@_*, not *ARGV*.  Drop
 >    that code fragment into a subroutine and watch it stop working!

It will not stop working, the semantics will change: It will simply
operate on a different array by default -- @ARGV outside of
subroutines, @_ inside. 

I think this exemplifies what you mean at the end of this post when
you say "Perl is hard because of the things it *hides*." What you mean
is a very innocent looking statement like:

  $x = shift;

can have context-sensitive effects, in this case, the context of
relevance being whether we are inside a subroutine or not. But we can
quell the context-sensitivity by giving shift and explicit arg:

$x = shift(@ARGV);
$x = shift(@_);

But Perl managed to make the default argument, the one you will be
most likely to use in each situation. Perl has a knack for being very
inconsistent in a very useful way. Unfortunately, this ease of use has
led to cut-and-paste cargo-cult type programming where people really
don't know why their code works even though it does work.

Another major area in which Perl code can become impossible to
understand are with what are known as ties, in which any of the normal
fetch and store operations for any Perl data type are replaced with
the fetch and store operations of a class "tied" to that variable.

People tie variables in Perl in all sorts of places. For example,
using the Tie::Cycle module (syntax approximate);

tie \$x, 'Tie::Cycle', qw(1 2 3);

print $x;  # => yields 1
print $x;  # => yields 2
print $x;  # => yields 3
print $x;  # => yields 1

And so we have another place where a very normal looking Perl variable
has had it's normal FETCH operation over-ridden and you cannot look at
this Perl code in isolation without knowing the semantics of
Tie::Cycle to understand what the output of this code segment is.

 > Terrence Brannon went on to say that
 > 
 > 	Thus, a program can either take values on STDIN or use hardcoded
 > 	defaults with relative ease.
 > 	
 > However, this code fragment has nothing whatsoever to do with STDIN.
 > He's talking about command-line arguments.

Oops. You are right. I wrote one thing but meant another.

 > Please don't think I'm picking on Terrence Brannon.  My point is simply
 > that someone who apparently *likes* Perl is confused by it.

I'm not confused by it. at least not at this level. But, in order to
keep things simple and focused on what I was trying to learn about
Mercury, I kept my Perl explanation far simpler and less precise than
the 15-line paragraph from the manual that you quoted, fraught as it
was with all sorts of foreign, complicating and largely irrelevant
Perl jargon.

And also, I don't really like Perl. I am a published author on Perl
(see perl.com and the upcoming issue #21 of the Perl Journal) and I am
maintainer for one important module (Data::Flow) and I make my living
as a senior Perl programmer at a major database corporation.  But, I
am spending my free time to make an escape from what Perl is and
hopefully at the same time make all things in Perl that are useful
(including all of CPAN) available within Mercury.

 > Perl is hard because of the things it hides.
 > Mercury is hard because of the things it *shows*.

Interesting comments, I will have to think about these for awhile.

I look forward to getting your book via amazon.com soon. But since you
recommended some others that seem more germane to my current efforts,
you may just have to wait awhile for your royalties from me to kick
in. :-)

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------