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
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
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
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
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 Sun, Mar 25, 2012 at 2:08 PM, Edward Kmett ekm...@gmail.com wrote:
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
On Sun, Mar 25, 2012 at 2:08 PM, Edward Kmett ekm...@gmail.com 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
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 believe
On Sun, Mar 25, 2012 at 4:03 PM, Daniel Peebles pumpkin...@gmail.com wrote:
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
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.
The
On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson n...@cs.nott.ac.uk 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
On Sun, Mar 25, 2012 at 5:39 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sun, Mar 25, 2012 at 6:54 PM, Henrik Nilsson n...@cs.nott.ac.uk 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
On 24 March 2012 12:53, Henrik Nilsson n...@cs.nott.ac.uk 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
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
apfel...@quantentunnel.de 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
On 24 March 2012 20:16, Ian Lynagh ig...@earth.li 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
apfel...@quantentunnel.de wrote:
Which brings me to the fundamental question behind this proposal: Why do we
On Sat, Mar 24, 2012 at 16:16, Ian Lynagh ig...@earth.li 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
On Sat, Mar 24, 2012 at 2:31 PM, Brandon Allbery allber...@gmail.com 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
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
On 24 March 2012 22:27, Ian Lynagh ig...@earth.li wrote:
On Sat, Mar 24, 2012 at 05:31:48PM -0400, Brandon Allbery wrote:
On Sat, Mar 24, 2012 at 16:16, Ian Lynagh ig...@earth.li wrote:
On Sat, Mar 24, 2012 at 11:50:10AM -0700, Johan Tibell wrote:
Using list-based operations on Strings are
On Sat, Mar 24, 2012 at 3:45 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org 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:
On 24 March 2012 22:33, Freddie Manners f.mann...@gmail.com 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
On Sat, Mar 24, 2012 at 3:33 PM, Freddie Manners f.mann...@gmail.com 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
On Sat, Mar 24, 2012 at 5:33 PM, Freddie Manners f.mann...@gmail.com 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
On Sat, Mar 24, 2012 at 6:00 PM, Johan Tibell johan.tib...@gmail.com 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
On Sat, Mar 24, 2012 at 4:42 PM, Gabriel Dos Reis
g...@integrable-solutions.net 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
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 5:54 PM, Gabriel Dos Reis
g...@integrable-solutions.net 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
On Sat, Mar 24, 2012 at 9:09 PM, Greg Weber g...@gregweber.info 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
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) code
that is easy to explain. If nothing else, this is pedagologically
2012/3/22 Greg Weber g...@gregweber.info:
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
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
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
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
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
On Fri, Mar 23, 2012 at 1:24 PM, Greg Weber g...@gregweber.info 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
On Fri, Mar 23, 2012 at 13:05, Edward Kmett ekm...@gmail.com 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
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.
On Fri, Mar 23, 2012 at 16:21, Nate Soares n...@so8r.es 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
On Fri, Mar 23, 2012 at 4:21 PM, Nate Soares n...@so8r.es 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
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
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)
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 :)
On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes christ...@siefkes.net
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
On Tue, Mar 20, 2012 at 2:25 AM, Simon Marlow simon...@microsoft.com 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
I actually was not able to successfully google for Text vs. String
benchmarks. If someone can point one out that would be very helpful.
On Sat, Mar 17, 2012 at 1:52 AM, Christopher Done
chrisd...@googlemail.com wrote:
On 17 March 2012 05:30, Tony Morris tonymor...@gmail.com wrote:
Do you know
Hi Greg,
There are a few blog posts on Bryan's blog. Here are two of them:
http://www.serpentine.com/blog/2009/10/09/announcing-a-major-revision-of-the-haskell-text-library/
http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/
Unfortunately the blog seems partly
On 17 March 2012 01:44, Greg Weber g...@gregweber.info wrote:
the text library and Text data type have shown the worth in real world
Haskell usage with GHC.
I try to avoid String whenever possible, but I still have to deal with
conversions and other issues.
There is a lot of real work to be
On 18 March 2012 19:29, ARJANEN Loïc Jean David arjanen.l...@gmail.com wrote:
Good point, but rather than specifying in the standard that the new string
type should be the Text datatype, maybe the new definition should be that
String is a newtype with suitable operations defined on it, and
On Mon, Mar 19, 2012 at 8:45 AM, Thomas Schilling
nomin...@googlemail.com wrote:
Regarding the type class for converting to and from that type, there
is a perhaps more complicated question: The current fromString method
uses String as the source type which causes unnecessary overhead. This
is
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.
On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes
christ...@siefkes.net 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 contain? A
This is the best I can do with Bryan's blog posts, but none of the
graphs (which contain all the information) show up:
http://web.archive.org/web/20100222031602/http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/
If someone has some benchmarks that can be ran that would be
...@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
| nomin...@googlemail.com wrote:
| Regarding the type class for converting to and from
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 johan.tib...@gmail.comwrote:
On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes
christ...@siefkes.net wrote:
On 03/19/2012 04:53
On Mon, Mar 19, 2012 at 2:55 PM, Daniel Peebles pumpkin...@gmail.com 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
Le 17/03/2012 02:44, Greg Weber a écrit :
the text library and Text data type have shown the worth in real world
Haskell usage with GHC.
I try to avoid String whenever possible, but I still have to deal with
conversions and other issues.
There is a lot of real work to be done to convert away
On 17 March 2012 05:30, Tony Morris tonymor...@gmail.com wrote:
Do you know if there is a good write-up of the benefits of Data.Text
over String? I'm aware of the advantages just by my own usage; hoping
someone has documented it rather than in our heads.
Good point, it would be good to collate
On 17/03/12 11:44, Greg Weber wrote:
the text library and Text data type have shown the worth in real world
Haskell usage with GHC.
I try to avoid String whenever possible, but I still have to deal with
conversions and other issues.
There is a lot of real work to be done to convert away from
73 matches
Mail list logo
