Andreas Raab <andreas.raab at gmx.de> wrote:
> Daniel,
> 
> Sigh. When will you actually start listening to what is said by all the
> people involved in this thread? 
I am listening, though I do agree at least some misunderstanding is
going on in this thread.

> Every time you write one of those "don't
> define a policy across all application" thingies you imply that clients are
> unable to change the policy. 
No I dont. Of course any squeaker and any squeak application *can*, in
some way, and maybe even quite simply, cause squeak to behave any way
they want. That is one of squeaks endearing qualities.

> How often has everyone to repeat that this is
> simply false? 
Zero. Nobody is claiming it.

> Defining a _default_ policy does not mean that any application
> which cares cannot change it. 
Of course. The default policy should be the one that causes the least
painful surprises. I claim that while system line-end auto-conversions
would remove some surprises, they would create more, and more painful
ones.

> The point about defaults is to capture the majority of use cases. 
No, the point about defaults is for them to be sensible. While most
programs that want to read text don't care about line endings are being
used, it is still not sensible to make autoconversions the default,
*because conflating two different abstractions is bad practice*. It is
still wrong for the class library to decide on line ending conversions
by default, because the common abstraction for text does not specify
line ending semantics, but lets programs and platforms do so, and many
do have an opinion on it. This means that control of this issue belongs
explicitly with the applications, by default. 

> And deny
> it as long as you want, in the vast majority of the cases where we deal with
> text, we _want_ a smart translation of line endings.
Same thing from another perspective - autoconverting stuff loses
information. I agree that sometimes this specific information is
meaningless, but sometimes it is meaningful. The cost of erring in the
two different directions is not the same. If you think it is, and that
mangling endlines indiscriminately is fine, then you're forgetting how
many peoples questions we've had to answer saying "your download client
thinks that line ends should automatically converted". Therefore, make
the safe setting the default, and let applications that know that their
formats are lineending oblivious say so explicitly. 

> Sure, every
> "application" could set this on its own, but then, why not just make it the
> default.
Because it is the wrong thing for a library to do?

> This is really silly. We're repeating the same arguments over and over.
No, we're not. Yours are changing - in your last reply you compared
EMACS to a library and compared the streams to ImageReaderWriter (which
is a reasonable exemplar of what I'm suggesting). I am also refining my
position - I thought for a while that I am being obnoxious over
something I invented. Alas, now I know that C and Python do what I
suggest. The scheme standard also waffles on this as does Smalltalks,
but mit-scheme at least has only the OS-compliant conversions, which I
can live with, but is somewhat primitive. 

I might not call this progress, but we're not in a fixed point :-)

But lets try to accelerate this to root out the precise differences.
What do you disagree with?
1. There are two separate useful abstractions - "line endings" and
"autodeciding line endings", which one might want to use separately (one
might want to read a file with a specified file ending, without
autodetection).
2. Text, in the wide world, is not uniformly defined as giving the same
meaning to cr/lf/cr+lf.
3. If squeak provides a non-standard abstraction, the interface to it
should hints at its semantics.

Daniel