Starting point for new standard?
Hi all, out of curiosity, what'll be the starting point for the next Haskell report? I suppose Haskell 2010 plus the additional "No Datatype Contexts" change accepted by the old Haskell Language committee in early 2011 (see https://wiki.haskell.org/Haskell_2010#Additional_change )? Best regards Christian -- |- Dr. Christian Siefkes - christ...@siefkes.net - | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ | Wie Produktion zur Nebensache wurde: www.keimform.de/2013/freie-quellen-1/ | Why Production No Longer Worries Us: www.keimform.de/2013/free-sources-1/ |--- OpenPGP Key ID: 0x980FA6ED -- 2 + 2 = 5 for suitably large values of 2. signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
Re: String != [Char]
On 03/26/2012 02:39 AM, Gabriel Dos Reis wrote: True, but should the language definition default to a string type that is one the most unsuited for text processing in the 21st century where global multilingualism abounds? Even C has qualms about that. ... I have no doubt believing that if all texts my students have to process are US ASCII, [Char] is more than sufficient. So, I have sympathy for your position. However, I doubt [Char] would be adequate if I ask them to shared texts from their diverse cultures. Uh, while a C char is (usually) just a byte (2^8 bits of information, like Word8 in Haskell), a Haskell Char is a Unicode character (2^21 bits of information). A single C char cannot contain arbitrary Unicode character, while a Haskell Char can, and does. Hence [Char] is (efficiency issues aside) perfectly adequate for dealing with texts written in arbitrary languages. Best regards Christian [I first accidentally send this just to Gabriel, sorry.] -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- A bug is a test case you haven't written yet. signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On 03/26/2012 01:26 PM, Gabriel Dos Reis wrote: It is not the precision of Char or char that is the issue here. It has been clarified at several points that Char is not a Unicode character, but a Unicode code point. Not every Unicode code point represents a Unicode code character, and not every sequence of Unicode code points represents a character or a sequence of Unicode character. What do you mean? Every Unicode character corresponds to one code point, and every code point in the range 0 to 0x10 (excluding the range 0xD800 to 0xDFFF which is reserved for surrogate pairs in UTF-16, and a handful of noncharacters, see http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Special_code_points ) corresponds to one character. Maybe your criticism is that Char does not explicitly prevent these special code points from being assigned? While true, that seems a relatively minor matter. Moreover, a future revision of the Haskell standard could easily declare that a assigning a forbidden character results in an error/bottom if that is so desired. Best regards Christian -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- Linux is like living in a tipi: no windows, no gates, Apache inside. signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On 03/26/2012 05:50 PM, Johan Tibell wrote: Normalization isn't quite enough unfortunately, as it does solve e.g. upcase = map toUppper You need all-at-once functions on strings (which we could add.) I'm just pointing out that most (all?) list functions do the wrong thing when used on Strings. Hm, do you have any other examples besides toUpper/toLower? Also, that example is not really an argument against using list functions on strings (which, by any reasonable definition, seem to be sequences of characters -- whether that sequence is represented as a list, an array, or something else, seems more like an implementation detail to me). Rather, it indicates the fact that Char.toUpper may have to wrong type. If its type was Char - String instead of Char - Char, it could handle things like toUppper 'ß' == SS correctly. Then stuff like upcase = concatMap toUppper would work fine. As it is, the problem seems to be with Char, not with [Char]. Best regards Christian -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- Failure is just success rounded down. -- Ryan North signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote: 2012/3/22 Greg Weber g...@gregweber.info: 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 ? I very much hope that the Haskell committee will never ever accept a proposal that will break many codebases! That's what ruined Perl 6 und Python 3, and quite unnecessarily so. Even if I a future Haskell standard defines String as something that doesn't have to be implemented as a list of Char, it still would have to behave as if it was [Char] for most practical purposes (except performance-wise, of course!). That's necessary for compatibility. Or String could just be complemented with an additional standardized Text type, as Greg suggested. Best regards Christian -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- Just so that nobody takes his guess for the full truth, here's my standing on keeping control, in 2 words (three?): I won't. -- Linus Torvalds, The Tanenbaum-Torvalds Debate signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
On 03/19/2012 04:53 PM, Johan Tibell wrote: I've been thinking about this question as well. How about class IsString s where unpackCString :: Ptr Word8 - CSize - s What's the Ptr Word8 supposed to contain? A UTF-8 encoded string? Best regards Christian -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- A choice of masters is not freedom. -- Bradley M. Kuhn and Richard M. Stallman, Freedom Or Power? signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
