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.
I'm persuaded by this argument. And I'm glad that teachers are speaking up in
this debate - it's hard to get a
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
On Mon, Mar 26, 2012 at 5:08 AM, Christian Siefkes
christ...@siefkes.net wrote:
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
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
On 26 March 2012 13:29, Christian Siefkes christ...@siefkes.net wrote:
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
On Sun, Mar 25, 2012 at 5:19 AM, Greg Weber g...@gregweber.info wrote:
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber g...@gregweber.info wrote:
Problem: we want to write beautiful (and possibly inefficient)
Can anyone explain how the tangent discussion of the finer points of
Unicode and the value of teaching [Char] is relevant to the proposal
under discussion? We aren't going to completely eliminate String and
break most existing Haskell code as Simon said. String is just a list
anyways, and lists
On Mon, Mar 26, 2012 at 8:35 AM, Gábor Lehel illiss...@gmail.com wrote:
On Sun, Mar 25, 2012 at 5:19 AM, Greg Weber g...@gregweber.info wrote:
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber g...@gregweber.info
On Mon, Mar 26, 2012 at 9:21 AM, Greg Weber g...@gregweber.info wrote:
Can anyone explain how the tangent discussion of the finer points of
Unicode and the value of teaching [Char] is relevant to the proposal
under discussion? We aren't going to completely eliminate String and
break most
I would like to get back to working on the proposal and determining
how Text can be added to the language.
The discussion started because of the question of whether Text should
support list processing functions at all, and if so how. That is a
very legitimate
question related to the Text
On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace malcolm.wall...@me.com wrote:
In the region of this side of the Atlantic Ocean where I teach, the
student population is very diverse
Prelude putStrLn (take 5 Fröhßen)
Fröhß
ghci putStrLn Fro\x0308hßen
Fröhßen
ghci putStrLn (take 5
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
On Mon, Mar 26, 2012 at 9:59 AM, Henrik Nilsson n...@cs.nott.ac.uk wrote:
So, is the argument to deprecate Char, then? As long as Haskell
allows Chars to be handled in isolation, it would seem impossible
to prevent naive users from accidentally stumbling over the
complexities of Unicode?
I
On Mon, Mar 26, 2012 at 10:12 AM, Ian Lynagh ig...@earth.li wrote:
I am very unicode-ignorant, so apologies if I have misunderstood
something, but doesn't Text do the same thing?
Prelude T import Data.Text.IO as T
Prelude T T T.putStrLn (T.take 5 (T.pack Fro\x0308hßen))
Fröh
Maybe your
On Mon, Mar 26, 2012 at 13:12, Ian Lynagh ig...@earth.li wrote:
Maybe your point is that neither take function should be used with
unicode strings, but I don't see how advocating the Text type is going
to help with that.
I think we established earlier that the list-like operations on Text
No-one's yet argued against OverloadedStrings. I think there /is/ an
argument to be made, that it introduces ambiguity and could break
existing programs (probably we can extend defaulting to take care of
Definitely, I have ones that would need some :: sprinkled in.
this, but I think there
16 matches
Mail list logo
