I am starting up the proposal.
http://hackage.haskell.org/trac/haskell-prime/ticket/143
http://hackage.haskell.org/trac/haskell-prime/wiki/OpaqueText
Unfortunately I haven't had any time to work on this for the last week
and won't for 2 more weeks.
Your help is appreciated. I think the first step
> "Gabriel" == Gabriel Dos Reis writes:
Gabriel> On Mon, Mar 26, 2012 at 5:08 AM, Christian Siefkes
Gabriel> It is not the precision of Char or char that is the issue
Gabriel> here. It has been clarified at several points that Char is
Gabriel> not a Unicode character, but a
Ben Millwood wrote:
> 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
> this, but I think there are people who'd be happier if we killed
>
> 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
On Mon, Mar 26, 2012 at 5:56 PM, Ben Millwood wrote:
> On Mon, Mar 26, 2012 at 6:21 PM, Brandon Allbery
> wrote:
> > On Mon, Mar 26, 2012 at 13:12, Ian Lynagh wrote:
> >>
> >> Maybe your point is that neither "take" function should be used with
> >> unicode strings, but I don't see how advocatin
On Mon, Mar 26, 2012 at 6:21 PM, Brandon Allbery wrote:
> On Mon, Mar 26, 2012 at 13:12, Ian Lynagh 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 es
On Mon, Mar 26, 2012 at 1:12 PM, Christian Siefkes
wrote:
> On 03/26/2012 06:58 PM, Johan Tibell wrote:
>> On Mon, Mar 26, 2012 at 9:42 AM, Christian Siefkes
>> wrote:
>>> On 03/26/2012 05:50 PM, Johan Tibell wrote:
Normalization isn't quite enough unfortunately, as it does solve e.g.
>
On Mon, Mar 26, 2012 at 11:42 AM, Christian Siefkes
wrote:
> 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
> someth
Can the unicode experts here propose a Text API whose functions work
for all Unicode (start by removing list functions)? If there is such a
satisfactory API and it does not conflict with the Prelude we could
use it unqualified.
On Mon, Mar 26, 2012 at 10:21 AM, Johan Tibell wrote:
> On Mon, Mar 2
On Mon, Mar 26, 2012 at 13:12, Ian Lynagh 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 are a
backw
On Mon, Mar 26, 2012 at 13:12, Ian Lynagh 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 are a
backw
On Mon, Mar 26, 2012 at 10:12 AM, Ian Lynagh 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 point
On Mon, Mar 26, 2012 at 9:59 AM, Henrik Nilsson 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 haven't proposed
On 03/26/2012 06:58 PM, Johan Tibell wrote:
> On Mon, Mar 26, 2012 at 9:42 AM, Christian Siefkes
> wrote:
>> 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 function
On Mon, Mar 26, 2012 at 06:08, Christian Siefkes 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 abounds? Even
On Mon, Mar 26, 2012 at 08:20:45AM -0700, Johan Tibell wrote:
> On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace
> 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ß
>
> gh
On Mon, Mar 26, 2012 at 9:42 AM, Christian Siefkes
wrote:
> 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 pointin
Hi all,
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.
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 u
On Mon, Mar 26, 2012 at 8:34 AM, Malcolm Wallace wrote:
> Yes indeed. And I think it would be perfectly reasonable for the String (=
> [Char]) API to have a function "normalise :: String -> String" which would
> let the user deal with this issue as they see fit. After all, if you are
> aware
On 26 Mar 2012, at 16:20, Johan Tibell wrote:
> On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace
> 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\
On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace 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 "Fro\x0308hßen")
Fröh
>>
>> 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
On 26 Mar 2012, at 15:30, Gabriel Dos Reis wrote:
> The Haskell Report claims very prominently that it uses the Unicode
> character set. The question is whether it should be using it correctly
> at all, and if so should it even try to pretend that its default string type
> use those characters c
On Mon, Mar 26, 2012 at 9:21 AM, Greg Weber 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 existing Haskell code
On Mon, Mar 26, 2012 at 8:35 AM, Gábor Lehel wrote:
> On Sun, Mar 25, 2012 at 5:19 AM, Greg Weber wrote:
>> On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
>> wrote:
>>> On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
>>
Problem: we want to write beautiful (and possibly inefficient) c
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 are
On Sun, Mar 25, 2012 at 5:19 AM, Greg Weber wrote:
> On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
> wrote:
>> On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
>
>>> Problem: we want to write beautiful (and possibly inefficient) code
>>> that is easy to explain. If nothing else, this is pe
On Mon, Mar 26, 2012 at 7:29 AM, Christian Siefkes
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 every Un
On 26 March 2012 13:29, Christian Siefkes 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 every Unicode cod
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 Mon, Mar 26, 2012 at 4:57 AM, Simon Marlow wrote:
> Remember that FilePath is not part of the debate, since neither [Char] nor
> Text are correct representations of FilePath.
Yes.
> If we want to do an evaluation of the pedagogical value of [Char] vs. Text, I
> suggest writing something li
On Mon, Mar 26, 2012 at 5:08 AM, Christian Siefkes
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 abounds? Even C
Hi all,
Simon Marlow wrote:
> So I'm far from convinced that [Char] is a bad default for the String
> type. But it's important that as far as possible Text should not be
> a second class citizen, so I'd support adding OverloadedStrings to
> the language, and maybe looking at overloading some
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 i
> 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
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
exaggerate
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis
wrote:
> On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson wrote:
>
>> In any case, this is hardly the place to to discuss how to best
>> teach Haskell or programming in general.
>
> Sure, I haven't seen any disagreement with that.
As interesting a
On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson wrote:
> In any case, this is hardly the place to to discuss how to best
> teach Haskell or programming in general.
Sure, I haven't seen any disagreement with that.
Note however that the "pedagogical" arguments was brought
in as support for the [C
Hi all,
Gabriel Dos Reis wrote:
> Look at the almost permanent damage done by the
> culture that equated 'char*' to strings. It may be inconvenient to
> say, but [Char] isn't any better -- in fact, I'll go further and say:
> it is spreading the same damage but only with a different syntax.
> Th
On Sun, Mar 25, 2012 at 4:03 PM, Daniel Peebles wrote:
> On Sun, Mar 25, 2012 at 3:47 PM, Gabriel Dos Reis
> wrote:
>>
>>
>> We are doing our students no favor, no good, in being condescending to
>> them pretending that they can't handle teaching material that would
>> actually
>> be close real w
On Sun, Mar 25, 2012 at 3:47 PM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
>
> We are doing our students no favor, no good, in being condescending to
> them pretending that they can't handle teaching material that would
> actually
> be close real world experience. If we truly belie
On Sun, Mar 25, 2012 at 2:08 PM, Edward Kmett wrote:
> If anything we delude ourselves by overestimating the ability of kids just
> shortly out of highschool to assimilate an entire new worldview in a couple
> of weeks while they are distracted by other things. Any additional
> distraction that m
On Sun, Mar 25, 2012 at 2:08 PM, Edward Kmett wrote:
> On Sun, Mar 25, 2012 at 11:42 AM, Gabriel Dos Reis
> wrote:
>>
>> Perhaps we are underestimating their competences and are
>> complicating their lives unnecessarily...
>
>
> Have you ever actually taught an introductory languages course?
Ye
On Sun, Mar 25, 2012 at 11:42 AM, Gabriel Dos Reis <
g...@integrable-solutions.net> wrote:
> Perhaps we are underestimating their competences and are
> complicating their lives unnecessarily...
>
Have you ever actually taught an introductory languages course?
If anything we delude ourselves by
On Sat, Mar 24, 2012 at 10:19 PM, Greg Weber wrote:
> On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
> wrote:
>> On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
>
>>> Problem: we want to write beautiful (and possibly inefficient) code
>>> that is easy to explain. If nothing else, this is p
Hi all,
Thomas Schilling wrote:
> OK, I agree that breaking text books is a big deal. On the other
> hand, the lack of a good Text data type forced text books to teach bad
> approaches to dealing with strings. Haskell should do better.
As far as I know, none of the introductory Haskell text b
On Sat, Mar 24, 2012 at 7:26 PM, Gabriel Dos Reis
wrote:
> On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
>> Problem: we want to write beautiful (and possibly inefficient) code
>> that is easy to explain. If nothing else, this is pedagologically
>> important.
>> The goals of this code are to
On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber wrote:
> # Switching to Text by default makes us embarrassed!
Text processing /is/ quick to embarrassment :-)
> Problem: we want to write beautiful (and possibly inefficient) code
> that is easy to explain. If nothing else, this is pedagologically
> im
On Sat, Mar 24, 2012 at 8:51 PM, Johan Tibell wrote:
> On Sat, Mar 24, 2012 at 5:54 PM, Gabriel Dos Reis
> wrote:
>> I think there is a confusion here. A Unicode character is an abstract
>> entity. For it to exist in some concrete form in a program, you need
>> an encoding. The fact that char1
# Switching to Text by default makes us embarrassed!
Problem: we want to write beautiful (and possibly inefficient) code
that is easy to explain. If nothing else, this is pedagologically
important.
The goals of this code are to:
* use list processing pattern matching and functions on a string ty
On Sat, Mar 24, 2012 at 5:54 PM, Gabriel Dos Reis
wrote:
> I think there is a confusion here. A Unicode character is an abstract
> entity. For it to exist in some concrete form in a program, you need
> an encoding. The fact that char16_t is 16-bit wide is irrelevant to
> whether it can be used
Can we all agree that
* Text can now demonstrate both CPU and RAM performance improvements
in benchmarks. Because Text is an opaque type it has a maximum
potential for future performance improvements. Declaring a String to
be a list limits performance improvements
* In a Unicode world, String = [C
On Sat, Mar 24, 2012 at 7:16 PM, Johan Tibell wrote:
> On Sat, Mar 24, 2012 at 4:42 PM, Gabriel Dos Reis
> wrote:
>> Hmm, std::u16string, std::u23string, and std::wstring are C++ standard
>> types to process Unicode texts.
>
> Note that at least u16string is too small to encode all of Unicode and
On Sat, Mar 24, 2012 at 4:42 PM, Gabriel Dos Reis
wrote:
> Hmm, std::u16string, std::u23string, and std::wstring are C++ standard
> types to process Unicode texts.
Note that at least u16string is too small to encode all of Unicode and
wstring might be as 16 bits is not enough to encode all of Uni
On Sat, Mar 24, 2012 at 6:00 PM, Johan Tibell wrote:
> C++'s char* is morally equivalent of our ByteString, not Text. There's
> no standardized C++ Unicode string type, ICU's UnicodeString is
> perhaps the closest to one.
Hmm, std::u16string, std::u23string, and std::wstring are C++ standard
typ
On Sat, Mar 24, 2012 at 5:33 PM, Freddie Manners wrote:
> To add my tuppence-worth on this, addressed to no-one in particular:
>
> (1) I think getting hung up on UTF-8 correctness is a distraction here. I
> can't imagine anyone suggesting that the C/C++ standards removed support for
> (char*) bec
On Sat, Mar 24, 2012 at 3:33 PM, Freddie Manners wrote:
> To add my tuppence-worth on this, addressed to no-one in particular:
>
> (1) I think getting hung up on UTF-8 correctness is a distraction here. I
> can't imagine anyone suggesting that the C/C++ standards removed support for
> (char*) bec
On 24 March 2012 22:33, Freddie Manners wrote:
> To add my tuppence-worth on this, addressed to no-one in particular:
>
> (1) I think getting hung up on UTF-8 correctness is a distraction here. I
> can't imagine anyone suggesting that the C/C++ standards removed support for
> (char*) because it w
On Sat, Mar 24, 2012 at 3:45 PM, Isaac Dupree
wrote:
> How is Text for small strings currently (e.g. one English word, if not one
> character)? Can we reasonably recommend it for that?
> This recent question suggests it's still not great:
> http://stackoverflow.com/questions/9398572/memory-effici
On 03/24/2012 02:50 PM, Johan Tibell wrote:
[...]
Furthermore, the memory overhead of Text is smaller, which means that
applications that hold on to many string value will use less heap and
thus experience smaller "freezes" due major GC collections, which are
linear in the heap size.
How is Tex
On 24 March 2012 22:27, Ian Lynagh wrote:
> On Sat, Mar 24, 2012 at 05:31:48PM -0400, Brandon Allbery wrote:
>> On Sat, Mar 24, 2012 at 16:16, Ian Lynagh wrote:
>>
>> > On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
>> > > Using list-based operations on Strings are almost always wr
To add my tuppence-worth on this, addressed to no-one in particular:
(1) I think getting hung up on UTF-8 correctness is a distraction here. I
can't imagine anyone suggesting that the C/C++ standards removed support
for (char*) because it wasn't UTF-8 correct: sure, you'd recommend people
use a d
On Sat, Mar 24, 2012 at 05:31:48PM -0400, Brandon Allbery wrote:
> On Sat, Mar 24, 2012 at 16:16, Ian Lynagh wrote:
>
> > On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
> > > Using list-based operations on Strings are almost always wrong
> >
> > Data.Text seems to think that many o
On Sat, Mar 24, 2012 at 08:38:23PM +, Thomas Schilling wrote:
> On 24 March 2012 20:16, Ian Lynagh wrote:
> >
> >> Correctness
> >> ==
> >>
> >> Using list-based operations on Strings are almost always wrong
> >
> > Data.Text seems to think that many of them are worth reimplementing fo
On Sat, Mar 24, 2012 at 2:31 PM, Brandon Allbery wrote:
> I was under the impression they have been very carefully designed to do the
> right thing with characters represented by multiple codepoints, which is
> something the String version *cannot* do. It would help if Bryan were
> involved with
On Sat, Mar 24, 2012 at 1:16 PM, Ian Lynagh wrote:
> Data.Text seems to think that many of them are worth reimplementing for
> Text. It looks like someone's systematically gone through Data.List.
> And in fact, very few functions there /don't/ look like they are
> directly equivalent to list funct
On Sat, Mar 24, 2012 at 16:16, Ian Lynagh wrote:
> On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
> > Using list-based operations on Strings are almost always wrong
>
> Data.Text seems to think that many of them are worth reimplementing for
> Text. It looks like someone's systemati
On 24 March 2012 20:16, Ian Lynagh wrote:
>
> Hi Johan,
>
> On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
>>
>> On Sat, Mar 24, 2012 at 12:39 AM, Heinrich Apfelmus
>> wrote:
>> > Which brings me to the fundamental question behind this proposal: Why do we
>> > need Text at all? Wha
Hi Johan,
On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
>
> On Sat, Mar 24, 2012 at 12:39 AM, Heinrich Apfelmus
> wrote:
> > Which brings me to the fundamental question behind this proposal: Why do we
> > need Text at all? What are its virtues and how do they compare? What is th
On 24 March 2012 12:53, Henrik Nilsson wrote:
> Hi all,
>
> Thomas Schilling wrote:
>
>> I think most here agree that the main advantage of the current
>> definition is only pedagogical.
>
> But that in itself is not a small deal. In fact, it's a pretty
> major advantage.
>
> Moreover, the utter s
Hi all,
On Sat, Mar 24, 2012 at 12:39 AM, Heinrich Apfelmus
wrote:
> Which brings me to the fundamental question behind this proposal: Why do we
> need Text at all? What are its virtues and how do they compare? What is the
> trade-off? (I'm not familiar enough with the Text library to answer thes
Hi all,
Thomas Schilling wrote:
> I think most here agree that the main advantage of the current
> definition is only pedagogical.
But that in itself is not a small deal. In fact, it's a pretty
major advantage.
Moreover, the utter simplicity of String = [Char] is a benefit
in its own right. Le
Edward Kmett wrote:
Like I said, my objection to including Text is a lot less strong than
my feelings on any notion of deprecating String.
[..]
The pedagogical concern is quite real, remember many introductory
lanuage classes have time to present Haskell and the list data type
and not much else
On Fri, Mar 23, 2012 at 4:21 PM, Nate Soares wrote:
> Note that this might be a good time to consider re-factoring the list
> operations, for example, making ++ operate on monoids instead of just
> lists.
Note: we have (<>) for Monoid, which was deliberately chosen rather than
generalizing (++)
On Fri, Mar 23, 2012 at 16:21, Nate Soares wrote:
> I think the 'naming issue' that you mention highlights the need for better
> use of type classes in the prelude.
...which is a rat's nest best avoided, unfortunately, unless the idea is to
stifle it entirely. (How long have people been propos
Note that this might be a good time to consider re-factoring the list
operations, for example, making ++ operate on monoids instead of just
lists. I think the 'naming issue' that you mention highlights the need for
better use of type classes in the prelude.
On Fri, Mar 23, 2012 at 1:03 PM, Thomas
OK, so I think we should separate the parts of the proposal a bit.
- Remove type String = [Char]
- Make String an abstract type (it could be named Text to encourage
users to think about whether they are operating on a representation
of text or on a sequence of bytes).
- Specify operatio
Like I said, my objection to including Text is a lot less strong than my
feelings on any notion of deprecating String.
However, I still see a potentially huge downside from an pedagogical
perspective to pushing Text, especially into a place where it will be front and
center to new users. String
> With regards to performance of fromString, I feel like if it was a
> serious problem (and how many really big strings are going to be built
> that way?) then an effort to do some special-case inlining (after all,
> the parameters are constant and specified at compile time) might be
> beneficial.
On Fri, Mar 23, 2012 at 13:05, Edward Kmett wrote:
> Isn't it enough that it is part of the platform?
>
As long as the entire Prelude and large chunks of the bootlibs are based
around String, String will be preferred. String as a boxed singly-linked
list type is therefore a major problem.
--
>From Greg Weber, *Fri Mar 23 14:24:24 CET 2012:*
>
> This proposal doesn't have to break any codebases.
> One possibility is to add the Text type to the standard while
> keeping String and marking it as deprecated.
I for one would like to go on the record as being against any notion of
"deprecat
On Fri, Mar 23, 2012 at 1:24 PM, Greg Weber wrote:
> I would really just like for someone to show me how to create a wiki
> proposal page :)
>
> This proposal doesn't have to break any codebases.
> One possibility is to add the Text type to the standard while keeping
> String and marking it as dep
Does Python 3 have the equivalent of LANGUAGE pragmas? That is, as a
GHC user i can add {-# LANGUAGE OLD_STRINGS -#} and my program works
with the new language standard!
I think what ruined Perl 6 is that it is still under development!
Avoiding breakage is important. But throwing around comparison
Hi,
ARJANEN Loïc Jean David wrote:
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
On 03/23/2012 02:13 PM, ARJANEN Loïc Jean David wrote:
> 2012/3/22 Greg Weber :
> 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
I would really just like for someone to show me how to create a wiki
proposal page :)
This proposal doesn't have to break any codebases.
One possibility is to add the Text type to the standard while keeping
String and marking it as deprecated.
On Fri, Mar 23, 2012 at 6:13 AM, ARJANEN Loïc Jean Da
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
On 3/22/12 5:49 PM, Greg Weber wrote:
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.
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
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 f
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 :)
__
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
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
On Tue, Mar 20, 2012 at 2:25 AM, Simon Marlow wrote:
> Is there a reason not to put all these methods in the IsString class, with
> appropriate default definitions? You would need a UTF-8 encoder (& decoder)
> of course, but it would reduce the burden on clients and improve backwards
> compati
> On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes
> wrote:
> > 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 c
On Mon, Mar 19, 2012 at 2:55 PM, Daniel Peebles wrote:
> If the input is specified to be UTF-8, wouldn't it be better to call the
> method unpackUTF8 or something like that?
Sure.
-- Johan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http:
If the input is specified to be UTF-8, wouldn't it be better to call the
method unpackUTF8 or something like that?
On Mon, Mar 19, 2012 at 12:59 PM, Johan Tibell wrote:
> On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes
> wrote:
> > On 03/19/2012 04:53 PM, Johan Tibell wrote:
> >> I've been th
On Mon, Mar 19, 2012 at 15:39, Simon Peyton-Jones wrote:
> Don't forget that with -XOverloadedStrings we already have a IsString
> class. (That's not a Haskell Prime extension though.)
>
I think that's exactly the point; currently it uses [Char] initial format
and converts at runtime, which is r
rime-
| boun...@haskell.org] On Behalf Of Johan Tibell
| Sent: 19 March 2012 15:54
| To: Thomas Schilling
| Cc: haskell-prime@haskell.org
| Subject: Re: String != [Char]
|
| On Mon, Mar 19, 2012 at 8:45 AM, Thomas Schilling
| wrote:
| > Regarding the type class for converting to and from
1 - 100 of 111 matches
Mail list logo
