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
sfactory method of dealing with Unicode in existence
> today? In that case, even if it /will be/ a good idea one day, can't
> we agree that it's not the right time to deprecate String = [Char]?
> The language has a good history, I understand, of not standardising
> that which is n
for text /per se/.
>
Does this mean we've firmly established that there currently is *no*
completely satisfactory method of dealing with Unicode in existence
today? In that case, even if it /will be/ a good idea one day, can't
we agree that it's not the right time to deprecate
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
o a sequence of two characters latin "f", meaning they "may be treated the
> same way in some applications (such as sorting and indexing), but not in
> others; and may be substituted for each other in some situations, but not in
> others".
>
> Is it realistic to thin
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
"f", meaning they "may be treated
the same way in some applications (such as sorting and indexing), but
not in others; and may be substituted for each other in some situations,
but not in others".
Is it realistic to think that if only Haskell used Text and not
String =
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 al
;Fröhßen")
>> Fröhß
>
> ghci> putStrLn "Fro\x0308hßen"
> Fröhßen
> ghci> putStrLn (take 5 "Fro\x0308hßen")
> Fröh
>
> Your example works because your input happens to be in a normal form.
Yes indeed. And I think it would be perfectly re
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
t does not matter much what the element type is as long as it follows
reasonable constraints. However, as someone observed earlier, the
Haskell Report is not a vehicle to prescribe how Haskell should be
taught or for what reasons Haskell should be taught. That argument,
while it was made to su
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
that performance should not come at the expense of good language design.
For pedagogical purposes (which seems to be the primary argument for
String = [Char]), I am far less concerned about performance than
correctness.
After going through the discussion this morning again, looking at
various argu
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
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
nt with that.
As interesting as this discussion is, I think this agreement is the
perfect segway to take it off list. Debating the usefulness of String
= [Char] does not seem to be productive here anyways. What would be
helpful is if alternatives were offered, tested out, and shared among
th
lms
about that.
> Given intimate knowledge of our specific teaching context
> here at Nottingham, I can say that removing String = [Char]
> from the language wouldn't be helpful to us.
I have no doubt believing that if all texts my students have to
process are US ASCII, [Char] is more
ledge of our specific teaching context
here at Nottingham, I can say that removing String = [Char]
from the language wouldn't be helpful to us.
And we do respect our students.
Best,
/Henrik
--
Henrik Nilsson
School of Computer Science
The
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
ly isn't the case that the Haskell world magically would
be significantly better of in terms of performance of only everyone
was forced to use something like Text instead of String = [Char].
Moreover, the above analysis is unnecessarily pessimistic for one
(somewhat important case: string l
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
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
ood engineering practice to worry about these things,
> but the standard isn't there to encourage good engineering practice.
(I assume you mean Unicode correctness. UTF-8 is only one possible
encoding. Also I'm not arguing for removing type String = [Char], I
arguing why Text is better
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
jor advantage.
>
> Moreover, the utter simplicity of String = [Char] is a benefit
> in its own right. Let's not forget that this, in practice,
> across all Haskell applications, works just fine in the vast
> majority of cases.
>
> I get the sense that the proponents fo
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 it
lives in unpinned memory
unlike ByteString.
I agree with Edward Kmett on the virtues of String = [Char] for
learning Haskell. I'm teaching beginners regularly and it is simply
eye-opening for them that they can use the familiar list operations to
solve real world problems which usually in
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
PM, Thomas Schilling
wrote:
> 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
&
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
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 :)
__
ibe 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
ode :: String -> [Char]
explode = ...
instance IsString [Char] where
fromString = explode
Tillmann
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
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 112 matches
Mail list logo