Re: String != [Char]
2012/3/22 Greg Weber : > I am not trying to win an argument with anyone. Just trying to do what > is best for the community. Many others here have a better grasp of the > issue than me and can help answer questions and come up with a > solution. > > I am also not saying this proposal is done. A lot of thought and work > is needed to ensure it can be implemented as smoothly as possible. It > does seem though that everyone thinks it is a good proposal. Sorry for the misunderstanding, but when you said that someone should take this proposal up and help make sure it gets in the next batch, I believed you thought we could take this proposal as is. Deeply sorry for my error. But now we have at least two tasks to do before we can put up the proposal: define what operations should be supported by String and should we apply this proposal in the next batch. Given that this proposal will break many codebases (we shouldn't hope to apply all of list's syntax to this string type) should we apply it alone or wait until we have more other codebase-breakers to apply ? -- ARJANEN Loïc Jean David http://luigiscorner.wordpress.com --- "Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do." Michael R. Fellows and Ian Parberry ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Le 22/03/2012 04:29, Greg Weber a écrit : This proposal seems fairly uncontroversial at the moment. I would really like it if someone more familiar with the proposal process can take this proposal up and help make sure it gets in the next batch. I can't even figure out how to create a wiki page for the proposal right now :) Well, this proposal seems uncontroversial because we didn't arrive to the difficult part: what operations should we define on this String type for it to be useful. Because with only this proposal as it stands now (String defined as an implementation-defined newtype, a typeclass defined for conversion from/to String and [Char] as an instance of this typeclass), we're in a worse situation than before: not only String became useless given there is no operations defined on it, the only mean we have to portably work with it is to translate it to [Char] before doing anything. So now, the fun part begins...what operations should String support ? I propose obtaining the length of a String, taking a substring of a given size beginning at a given index, taking the character at index i in a String, concatenation, converting a string to upper/lower case and determining if a string is contained in/a prefix/a suffix of another. I am sure I am forgetting some useful operations and some operations I said are better placed in the typeclass or in a typeclass instance or are particular cases of general operations we should define rather than the particular cases. So, what are the operations we should define according to you ? Regards, ARJANEN Loïc ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Le 20/03/2012 16:29, Tillmann Rendel a écrit : Hi, Thomas Schilling wrote: I agree that the language standard should not prescribe the implementation of a Text datatype. It should instead require an abstract data type (which may just be a newtype wrapper for [Char] in some implementations) and a (minimal) set of operations on it. Regarding the type class for converting to and from that type, there is a perhaps more complicated question: The current fromString method uses String as the source type which causes unnecessary overhead. Is this still a problem if String would be replaced by an implementation-dependend newtype? Presumably, GHC would use a more efficient representation behind the newtype, so the following would be efficient in practice (or not?) newtype String = ... class IsString a where fromString :: String -> a The standard could even prescribe that an instance for [Char] exists: explode :: String -> [Char] explode = ... instance IsString [Char] where fromString = explode Tillmann A recent message on Haskell-café made me think that if the standard mandates that any instance exists, it should mandates that an instance exists for CString and CWString (C's strings and wide strings) or, more generally, that an instance exists for any foreign string type defined in the FFIs implemented. That is to say, if you implement a FFI for .Net and you expose .Net's string type, you should implement conversions between that string type and Haskell's one. Regards, ARJANEN Loïc ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
Le 17/03/2012 02:44, Greg Weber a écrit : the text library and Text data type have shown the worth in real world Haskell usage with GHC. I try to avoid String whenever possible, but I still have to deal with conversions and other issues. There is a lot of real work to be done to convert away from [Char], but I think we need to take it out of the language definition as a first step. I can only see one issue with the proposal: it can be convenient to operate on a list of characters. But I think there are plenty of solutions at our disposal. A simple conversion from Text to a list of characters might suffice. In GHC, OverloadedStrings means users would still be free to use String the same way they are now. Good point, but rather than specifying in the standard that the new string type should be the Text datatype, maybe the new definition should be that String is a newtype with suitable operations defined on it, and perhaps a typeclass to convert to and from this newtype. The reason of my remark is although most implementations compile to native code, an implementation compiling to, for example, JavaScript might wish to use JavaScript's string type rather than forcing its users to have a native library installed. Regards, ARJANEN Loïc ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
