On Tue, Feb 07, 2006 at 06:38:14PM +0000, Robin Houston wrote:
: Late last year I implemented a few Perl 6 features in Perl 5.
: A couple of things have emerged that may be relevant to the
: Perl 6 design. Certainly they're things that I'm curious about.
: I'll send the other one in a separate message to keep the
: threads apart: this message is about 'say'.
:
: The definition of 'say' is very simple:
:
: say <foo>
:
: is exactly equivalent to
:
: print <foo>, "\n"
:
: and that's just the way it works in Perl 5.9.3. In fact,
: that's how it's compiled. A few people on p5p have expressed
: some disquiet that
:
: say "foo";
:
: will print the string "foo$,\n$\". I'm inclined to agree that
: this seems sensible only when $, and $\ are both empty, as
: they are by default.
:
: I'm not sure what the Perl 6 analogues are of $, and $\. I've
: heard that $\ is a per-filehandle setting. Is there any analogue
: of $,? Presumably there is.
Yes, native Perl 6 will attach such things to the filehandle objects,
though the p5-to-p6 translator will have to emulate them somehow...
: In short, I'm curious as to why say is defined as it is, rather
: than, for example, to be the equivalent of the Perl 5 code
:
: { local $\ = "\n"; print <foo> }
:
: I've searched the archives of this list, but failed to turn
: up anything relevant.
You're searching the wrong archives. :-) Here's something from the
@Larry's archives--Damian first brought this up almost two years ago,
and I don't think he'll mind me forwarding the last message in that
thread:
> From [EMAIL PROTECTED] Sun Jan 23 14:31:50 2005
> Message-ID: <[EMAIL PROTECTED]>
> Date: Mon, 24 Jan 2005 09:31:36 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> To: Perl 6 Design Team <[EMAIL PROTECTED]>
> Subject: Revisiting an old decision (after extensive play-testing)
> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
> PROTECTED]> <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Length: 2404
> Lines: 56
>
> Some time back, we were discussing the C<say> function, and its interaction
> with a filehandle's ORS:
>
> > On Fri, Mar 26, 2004 at 01:01:28PM +1100, Damian Conway wrote:
> > : So, how (if at all) does C<say> interact with the filehandle's output
> > : record separator? Does it:
> > :
> > : a. Temporarily set the filehandle's ORS to newline and call C<print>?
> > : (i.e. just append: "\n")
> > :
> > : b. Temporarily set the filehandle's ORS to newline unless that ORS is
> > : already defined as something else and call C<print>?
> > : (i.e. append: $fh.outsep // "\n")
> > :
> > : c. Append a newline and call C<print>, which then appends the
> > : filehandle's ORS?
> > : (i.e. append: "\n" ~ $fh.outsep)
> > :
> > :
> > : d. Append the filehandle's ORS, then a newline, and output directly?
> > : (i.e. append: $fh.outsep ~ $fh)
> > :
> > :
> > : Personally, I think a. or b. would probably be the least surprising.
> >
> > I think b. seems likeliest to do what they want. Of course, it doesn't
> > actually have to be implemented in terms of print.
>
> I've now been using C<say> (via Perl6::Say) for some time -- testing our
> collective intuition on this -- and it turns out that b. isn't the least
> surprising. At least, not to me. In fact, I am regularly (and annoyingly)
> re-surprised every time $\ overrides what I was sure was going to be newline.
>
> I've realised that this is because I constantly abstract C<say> in terms of
> C<print>. Specifically, as "print <args> plus a newline".
>
> But the b. semantics constantly thwart that unconscious abstraction, giving
> me
> instead "print <args> plus *sometimes* a newline, but sometimes not".
> That's because, if $\ is set, C<say> devolves to exactly C<print> (which also
> seems somehow "wasteful").
>
> I have the definite sense that C<say> is going to be one of the most-used
> features of Perl 6 (it's certainly the one I use most so far), so I'd
> strongly
> suggest that we revisit its semantics to make them less surprising.
>
> In particular, I think the simplest, most useful, and most predictable
> semantics are actually those suggested in alternative c. above. That is, I
> think the following equivalence should hold exactly:
>
> say @args <====> print @args, "\n"
>
> That's definitely how I find myself thinking about C<say> when I'm not
> actually...err...thinking about C<say>, so I think that's what might fit
> hacker brains most naturally.
>
> Damian
The question basically boils down to how you think about "say".
Damian's argument is that, if people are like him, they will learn
it as "print plus newline" rather than as "emit a whole record".
I'm inclined to think that people do in fact learn one feature in
terms of other features like that, rather than treating "say" as a
different primitive.
It would be nice to have other data points, though, since I think
even Damian will admit that Damian's brain doesn't work like everyone
else's brain. An argument can also be made that we should do 'b'
anyway for "generality" even if it does surprise people occasionally.
We could experiment--maybe try 'b' in Pugs for a while and see if other
people carp, I suppose, if we can't puzzle it out from first (or second)
principles.
Another confounding factor is that we're all familiar with Perl 5's
print already. It's not entirely clear that a new learner of Perl
would learn "say" in terms of "print".
Of course, we could fix the whole problem by renaming it to "printline". :-)
Larry
