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
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
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
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 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 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
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 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 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 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 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
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 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
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 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 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: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 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 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 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 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
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 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
# 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 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
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 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
27 matches
Mail list logo
