Re: The definition of 'say'
At 21:30 +0100 2/8/06, Juerd wrote: >Larry Wall skribis 2006-02-08 8:38 (-0800): > > It would be nice to have other data points In the Macintosh world: 1) say is a reserved word in AppleScript that sends text to a speaker (with windings and a cone). 2) We are forever mucking with $/ and $\ set to different values. One for reading someone else's file and the other for writing something the Macintosh way. (It's better in OS neXt.) And everywhere: 3) There are two more 16 bit line ends in unicode that may or may not ever be really used. -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: The definition of 'say'
Larry Wall skribis 2006-02-08 8:38 (-0800):
> It would be nice to have other data points
I associate "say" with to-human communication, and there, I don't
generally have records. Without records, no ORS.
However, while I think that &say should not be
&print.assuming(:ors("\n")), it shouldn't be print + \n either.
Instead, I think the format should be configurable, defaulting to
suffixing \n, but configurable to have another suffix, and possibly a
prefix even. For example, I may very well like a "* %s\n"-like output,
or when dealing with HTML, "%s".
Of course, I could just override &say. But I think making it
configurable and documenting the difference between say and print as a
difference in final recipient (human versus computer) may make more
sense.
In any case, &say being print + \n as the default is IMO a better plan
than having it default to any ORS, even if that ORS happens to be \n.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: The definition of 'say'
On 2/8/06, Larry Wall wrote: > From: Damian Conway <[EMAIL PROTECTED]> > I've now been using C (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. The question basically boils down to how you think about "say". I guess I think of "say" as "print + \n" too... because that's how everyone explains it. If we told everyone it meant "print + ORS", I think it would be less surprising. Of course, I hardly ever set a record separator, and I'm not sure what Damian was doing that led him to want to set one and to use 'say' at the same time. What's the difference between an ORS and a newline anyway? The purpose of a newline is typically to provide a visual separation... hm. Maybe we should take a step back: 'say' and ORS's are both a kind of shortcut to save you from typing everything out explicitly in every print statement. What if 'print' never added anything to its output, and 'say' always added the field and record separators? The default ORS should then be \n. Instead of turning the separators on and off (as in P5), you would switch between using 'print' and 'say'. (You might also make an argument that the default OFS should be a space or a tab, but I think OFS="" and ORS="\n" are probably what most people want most of the time. That certainly fits my typical uses of 'print' and 'say'.) -David "say what?" Green
Re: The definition of 'say'
One more data point?
I might want a newline or I might want an ORS. The former, say()
gives me. The latter, print() provides.
I cannot imagine ever wanting a mixture of those, and if I ever do,
I expect I'll prefer to say what I mean:
# modulo syntax:
{ temp ORS //= "\n"; print @args } # b
print @args, "\n"; # c
{ temp ORS ~= "\n"; print @args } # d
In the common case, I think I'll have one or the other, and no
surprises, if you please. Option a.
Eirik
--
Habit is a cable; we weave a thread of it each day,
and at last we cannot break it.
--Horace Mann
Re: The definition of 'say'
On Wed, Feb 08, 2006 at 08:38:32AM -0800, Larry Wall wrote: > 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. Just as another data point, I too have been thinking of "say" as "print + newline". -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: The definition of 'say'
IMHO, people who set $/ are, by definition, saying that they expect lines to terminate with something other than a newline; they should expect 'say' to conform to their wishes. I don't like the notion of perl second-guessing the programmer's intentions here; "Do what I mean, not what I say" only carries so far. That said, I very rarely set $/, so this aspect of 'say' doesn't really affect me. -- Jonathan Lang
Re: The definition of 'say'
On Tue, Feb 07, 2006 at 06:38:14PM +, 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
:
: is exactly equivalent to
:
: print , "\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 }
:
: 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 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 interact with the filehandle's output
> > : record separator? Does it:
> > :
> > : a. Temporarily set the filehandle's ORS to newline and call C?
> > : (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?
> > : (i.e. append: $fh.outsep // "\n")
> > :
> > : c. Append a newline and call C, 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 (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 in terms of
> C. Specifically, as "print plus a newline".
>
> But the b. semantics constantly thwart that unconscious abstraction, giving
> me
> instead "print plus *sometimes* a newline, but sometimes not".
> That's because, if $\ is set, C devolves to exactly C (which also
> seems somehow "wasteful").
>
> I have the definite sense that C 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 when I'm not
> actually...err...thinking about C, 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 h
