NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/perl/5913

Internet Message Format | 1992-09-13 | 3.5 KB

Path: sparky!uunet!usc!wupost!micro-heart-of-gold.mit.edu!eddie.mit.edu!minya!jc
From: [e-mail] (John Chambers)
Newsgroups: comp.lang.perl
Subject: Re: "return <STDIN>;" doesn't work
Message-ID: <[e-mail]>
Date: 14 Sep 92 02:07:41 GMT
References: <[e-mail]> <[e-mail]>
Lines: 71

In article <[e-mail]>, [e-mail] (Larry Wall) writes:
> In article <[e-mail]> [e-mail] (John Chambers) writes:
> :    for ($l = &getline()) ...
> : I simplified the subroutine to:
> :    sub getline {
> :       return <STDIN>;
> :    }
> : and it returned a null value.  To find out what the @*&*!$^@ was
> : going on, I rewrote it as:
> :
>
> Note that the book says "return LIST".  That puts <STDIN> into a list
> context, so <STDIN> is going to return The Whole Thing.  You need to say
>
>    return scalar <STDIN>;
>
> I'm a little surprised that you say it returned a  null  value.   It
> should have returned the last line of the file. The last line wasn't
> blank, was it?

Well, I don't think so, but it was a while ago, and that  part  of  my
memory  has  since been freed and alloced for other uses.  I guess the
confusion, which I haven't  been  able  to  quite  get  straight  from
reading the camel book, is something like: I didn't quite pick up that
the "return LIST" meant that return imposes a list context on its arg.
I  had understood it to mean that return accepts a list as an arg, but
this seems to me to not mean quite the same thing.  After all,  the  =
operator  will  accept a list as either arg, and yet it doesn't impose
array context on all its args.  So  it  seems  clear  that  there  are
functions  in  perl  that  will accept either scalor or list args, and
evaluate them in either context.  This  idea  was  reinforced  by  the
warnings  about the scalar/list context being inherited from outside a
function call.  It somehow  seemed  that  return  should  inherit  the
calling  context  if  anything  in  a function did, and since I hadn't
picked up on the idea that saying LIST in a function  prototype  meant
an imposition of list context (just the willingness of the function to
accept a list if offered one ;-), I wasn't expecting the list  context
here.

Jeez, did any of that make sense?

Anyhow, I'll reread chapter four with the new understanding that  LIST
is code for the imposition of list context, and maybe I won't make the
same mistake in the future.  I'm sure that  I  still  have  unutilized
mistakes  that  I  can  make  instead.   I'm  not  at  all sure that I
understand what the rules are for passing along the context, so  there
are likely still some mistakes to be made there..

Another thing I discovered that surprised  me  was  that  when  I  got
around to writing the routine
    sub getline {
       <STDIN>;
    }
it  behaved  differently  than  the  one with return in it.  I've used
several languages in which the last expression in a  function  is  the
return  value (and I was somewhat disappointed with C for not doing it
this way ;-).  In all of  them  that  I've  seen  so  far,  the  final
statements:
    x
and
    return x
are  equivalent.   It's  a  bit surprising that this isn't the case is
perl.  Was this a conscious  design  decision  (presumably  with  some
reason  that I can't fathom), or did it just sort of happen?  Is there
some clever use of this definition of return?

--
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc
--
Pensu tutmonde; agu loke.