On Sun, 12 Dec 2004 06:18:47 +0900, Yukihiro Matsumoto
<matz / ruby-lang.org> wrote:
> 
> In message "Re: puts / print as method not keyword?"
>     on Sun, 12 Dec 2004 05:38:33 +0900, zuzu <sean.zuzu / gmail.com> writes:
> 
> |and so i also feel that
> |
> |   string.puts(STDOUT)
> |
> |or i'm probably thinking more like
> |
> |   string.puts {STDOUT}
> |
> |much more closely follows the so-called "Principle of Least Surprise".
> 
> It is very interesting to see how POLS differ person to person.
> That's one of the reasons I discourage use of the word POLS in any
> proposal. ;-)

quite true.  it's quite subjective.

> "puts" was taken from UNIX C output function, which takes an output
> string as an argument, so that it is more natural (for me at least) to
> take functional form.  I would be astonished very much when puts takes
> output destination as an argument.

this makes sense.  particularly due, as you say, to experience with unix c.

> "display" was inherited from Smalltalk.

aaaah, very interesting.

> |see, my concern then is that the "to where?" question becomes much
> 
> 
> |more obvious in the second, and much more necessary as ruby grows
> |beyond just a virtual machine running inside a unix environment or as
> |ruby grows as a networked language.   perhaps i don't just want the
> |default STDOUT but would like to specify tty3 versus tty9 or perhaps
> |window7 of some screen tty multiplexing session or how emacs manages
> |buffers, and so on...
> |
> |oh, also, correct me if i'm wrong, but method/function argument
> |passing really should only be used for CONSTRAINTS _not_ DATA.
> 
> I don't see any obvious reasons behind your opinion.  Can you
> elaborate?
> 
>                                                         matz.

for the function argument issue...  i think the idea of constraints
has its origins in math just as the idea of a function does.  however,
i encounter it much more vocally in the study of process in the fields
of systems theory and cybernetics.  when utilizing a process model to
solve a problem, a differentiation is made between variables (the
unknowns you seek to know) and constraints (arbitrary filters to limit
the search space).
however, this does become not so obvious in the real world where the
data output from one function can define the constraints input into
another function.  but in many dataflow languages, and i think even in
the useful difference between closures and function arguments, a
distinction is made between the dataflow and "defining the filters"
(constraints).

as for the issue of defining what STDOUT is set to...  this seems
"obvious" to me because of the dataflow involved, moving a stream
linearly from inputs to outputs.  usually a screen or printer to
teletype or such is the "final" output / destination, or at least
represents the intersection where that stream of information is then
input into a human and an "input device" such as a keyboard or mouse
receives human output back into the computer -- so thus a cycle of
human-computer interaction persists with the human as just another
filter/generator.

i hope i explained this well.  i will be happy to elaborate futher.
-z