John Meacham wrote:
ajb@spamcop.net wrote: ...
As a matter of pure speculation, how big an impact would it have if, in the next "version" of Haskell, Strings were represented as opaque types with appropriate functions to convert to and from [Char]? Would there be rioting in the streets?
I also have wondered how much the string representation hurts haskell program performance.. Something I'd like to see (perhaps a bit less drastic) would be a String class, similar to Num so string constants would have type String a => a
then we can make [Char], PackedString, and whatnot instances. It should at least make working with alternate string representations easier.
One - among many - reasons why I use Clean [[and for some years I cannot decide whether Haskell is the legitimate wife, and Clean a responsive mistress, or vice-versa...]] is that strings being unboxed arrays permit easily to communicate with lower-level binary file processing, which may be then processed by higher-level code. Thus, I can easily read and write image files (at least uncompressed, say .bmp), binary sound files, etc. There is nothing fundamental there, simply a string *is* almost directly the file buffer. Haskell introduces some overhead. I believe that the only advantage of keeping string as lists is to facilitate their lazy processing. Writing parsers and other loooong string consumers. But, as ajb said above, it can pass through a lazy conversion stage, comprehensions, etc. Jerzy Karczmarczuk Caen, France