[Haskell-cafe] Writing binary files?
GK at ninebynine.org
Wed Sep 15 07:42:03 EDT 2004
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
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
>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
More information about the Haskell-Cafe