John Meacham wrote:
[EMAIL PROTECTED] 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
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
