but the whole point of the module was to finally distingwish between
Bytes and Chars and provide a base mechanism which allows machine and
compiler independant IO with haskell.. i mean what is the point of a
strong type system if we go out of our way to loose distinctions between
values, a raw byte stream and a String are two very different entities
and should not be equivalated. 

also, there needs to be a simple mechanism which gets rid of all that
\r\n <-> \n conversion and any sort of processing on the data. it is
fine to have hGetContents which gets text out of a file as approprate
for your system, but rarely, in fact almost never, is that what i
actually want to do with IO, you usually have a well-specified, exact
format of data you wish to read or write which is independant of the
system or architecture you happen to be running on, 
examples of projects i had to dump haskell for because of no binary IO
are: 

fractal audio compression (a WAV file contaions big endian 4 byte
numbers interpreted as a 32 bit value, there is no way to read that) 

a gale messageing system client. (again various binary specified data)
fake nfs server to distribute shared info for a cluster. (need to
formulate raw XDR data which is defined as a byte stream.) 

a web browser. sometimes you get jpeg's sometimes you get ASCII somtimes
you get UTF16 LittleEndian off of a socket. i cannot and should not
expect conversions everything to be built into the language. i just want
a byte stream from the socket i can interpret as i see fit.

none of these use character data, the haskell code to deal with these
formats would be simple and clean, and with even the simplest binary io
it could be done trivially, but in every case i had to switch to
another language all togeter or for glue code because haskell does not
cut it for no particular reason.

also TCP is defined as providing an uninterrupted, ordered byte
stream, NOT a character stream. also under unix i often produce dos
files and vice versa, i dont want any sort of built in crlf conversion
for that...

i totally would like to see everything you wrote about in an interface,
but it does not seem like a good base implementation of functionality
for a language, it can all easily be written in pure haskell as an extra
library if we are just given access to an underlying byte stream with no
tampering.

I should also mention that this is in no means meant to replace the
various binary mechanisms that different platforms use (module Binary in
nhc, Storeable in ghc, etc..). but rather it is meant to be built on top
of that, it is a very simple bare bones interface which has clear
semantics which are completely independant of platform, compiler and OS
which is VITAL functionality for writing portable programs. most times
you dont want programs that are magically localized to where they are
run, you want programs that act the exact same way everywhere. Char's
depend on local conventions, Bytes do not. crlf conversion, utf8
encoding and whatnot can all be implemented trivially in haskell itself
on top of raw IO and specified by the standards independantly.  remember
the lessons of FFI, provide the barest functionality and build on it in
haskell itself, it allows more compeditive evolution of ideas, code and
interfaces.


sorry if it seems that i am ranting, but i dont know how to express the
frustration i felt when i spent days trying to write a simple portable
haskell program that can read in a WAV file but finally came to the
conclusion that in my language of choice, i could not complete even
simple tasks such as this. it also does not help when i wish to show
haskell off to other people or my students, 90% of what people first
think of as progects to test out the language do not use string based
IO, and i had to explain why these simple tasks could not be done in
this language which i have been promoting as da' bomb.

-- 
--------------------------------------------------------------
John Meacham   http://repetae.net/~john/   [EMAIL PROTECTED]
California Institute of Technology, Alum.  [EMAIL PROTECTED]
--------------------------------------------------------------

Reply via email to