[Haskell-cafe] Writing binary files?

[Graham Klyne]

I've not been following this debate, but I think I agree with Ross.

In particular, the idea of "narrowing" the Char type really seems like a 
bad idea to me (if I understand the intent correctly).  Not so long ago, I 
did a whole load of work on the HaXml parser so that, among other things, 
it would support UTF-8 and UTF-16 Unicode (as required by the XML 
spec).  To do this depends upon having a Char type that can represent the 
full repertoire of Unicode characters.

Other languages have been forced into this (maybe painful) transition;  I 
don't think Haskell can reasonably go backwards if it is to have any hope 
of surviving.

#g
--

At 12:31 15/09/04 +0100, ross at soi.city.ac.uk wrote:
>On Mon, Sep 13, 2004 at 12:01:58PM +0100, Glynn Clements wrote:
> > My view is that, right now, we have the worst of both worlds, and
> > taking a short step backwards (i.e. narrow the Char type and leave the
> > rest alone) is a lot simpler (and more feasible) than the long journey
> > towards real I18N.
>
>This being Haskell, I can't imagine a consensus on a step backwards.
>In any case, a Char type distinct from bytes and the rest is the most
>valuable part of the current situation.  The rest is just libraries,
>and the solution to that is to create other libraries.  (It's true
>that the Prelude is harder to work around, but even that can be done,
>as with the new exception interface.)  Indeed more than one approach
>can proceed concurrently, and that's probably what's going to happen:
>
>         The Right Thing proceeds in stages:
>         1. new byte-based libraries
>         2. conversions sitting on top of these
>         3. the ultimate I18N API
>
>         The Quick Fix: alter the existing implementation to use the
>         encoding determined by the current locale at the borders.
>
>When the Right Thing is finished, the Quick Fix can be recast as a
>special case.  The Right Thing might take a very long (possibly infinite)
>time, because this is the sort of thing people can argue about endlessly.
>Still, the first stage would deal with most of the scenarios you raised.
>It just needs a group of people who care about it to get together and
>do it.
>
>The Quick Fix is the most logical implementation of the current
>definition of Haskell, and entirely consistent with its general
>philosophy of presenting the programmer with an idealized (some might
>say oversimplified) model of computation.  From the start, Haskell
>has supported only character-based I/O, with whatever translations
>were required to present a uniform view on all platforms.  And that's
>not an entirely bad thing.  It won't work all the time, but it will be
>simple, and good enough for most people.  Its existence will not rule
>out binary I/O or more sophisticated alternatives.  Those who need more
>may be motivated to help finish the Right Thing.
>_______________________________________________
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org
>http://www.haskell.org/mailman/listinfo/haskell-cafe

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact