Hi all, > 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.
Even if we accept these allegation (and I think they are greatly exaggerated), a reasonable position would be yes, for reasons of simplicity and backwards compatibility, given that just the change of default definition of "String" in itself is hardly going to do anything to make it easier to write software that truly can cope with any language. The latter requires tools, libraries, and knowledge well beyond what reasonably should go into any programming language standard. > 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. > Should the language definition make it much harder to share such > experience in classroom when the primary argument for [Char] > is pedagogy? The primary argument is to not break something that works well for most purposes, including teaching, at a huge cost of backwards compatibility for marginal if any real benefits. What would be helpful here is if you could clarify exactly what would stop someone using a library like Text in an exercise like the one you outline above if String = [Char] remains in the language. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime