Re: Why are strings linked lists?
(shifting to Haskell-Cafe) On Fri, 28 Nov 2003, Donald Bruce Stewart wrote:
ajb: (snip)
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'd be sad to lose some convenient list-based string type because I make a lot of use of the fact that strings are lists in processing them.
You could look at GHC's FastString representation (used internally). It is in $fptools/ghc/compiler/utils/FastString.lhs
It does make sense to have a rather faster form of string conveniently available in /some/ form. -- Mark
On Fri, Nov 28, 2003 at 04:56:02PM -0500, Mark Carroll wrote:
(shifting to Haskell-Cafe)
On Fri, 28 Nov 2003, Donald Bruce Stewart wrote:
ajb: (snip)
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'd be sad to lose some convenient list-based string type because I make a lot of use of the fact that strings are lists in processing them.
I agree. What I think might be a nice compromise at some point would be to have a "String" class, which would support conversion to either String or to PackedString, or to CString. Then library functions wanting a String parameter could accept a parameter of any instance of the String type. Functions returning a string could do so using whatever is the most efficient/convenient instance of class String. Perhaps that would be overkill, but it would be nice to be able to do (for example) a getCurrentDirectory and corresponding setCurrentDirectory without ever converting the directory name from a CString to a String (presuming the standard system calls used by getCurrentDirectory etc accept CStrings). -- David Roundy http://www.abridgegame.org
At 16:56 28/11/03 -0500, Mark Carroll wrote:
(shifting to Haskell-Cafe)
On Fri, 28 Nov 2003, Donald Bruce Stewart wrote:
ajb: (snip)
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'd be sad to lose some convenient list-based string type because I make a lot of use of the fact that strings are lists in processing them.
+1 Following this debate, I find myself wondering if this is not something that might be optimized "behind the scenes" as a common case, rather than changing the computational model presented. I use strings a lot, and thus far I've not been aware that they've been a performance problem for me. #g --
You could look at GHC's FastString representation (used internally). It is in $fptools/ghc/compiler/utils/FastString.lhs
It does make sense to have a rather faster form of string conveniently available in /some/ form.
-- Mark _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
On Sat, 29 Nov 2003, Graham Klyne wrote:
Following this debate, I find myself wondering if this is not something that might be optimized "behind the scenes" as a common case, rather than changing the computational model presented.
Argh, please, no! I find this kind of implicit optimisation can be very annoying. If you aren't relying on good performance, and it goes a bit faster than expected, that's great. But if you are relying on fast strings, you really don't want to be depending on the compiler optimising things... because you'll spend half your time trying to work out whether the optimisation has been applied, and if not, what change you made that meant that the compiler couldn't do the optimisation... N
participants (4)
-
David Roundy -
Graham Klyne -
Mark Carroll -
Nicholas Nethercote