Re: String != [Char]
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 (++) because that had already changed meaning from applying to MonadPlus to the more restricted type during what I tend to refer to as the "great momomorphization revolution of 1998", and not every MonadPlus is compatible with the corresponding monoid (Maybe comes to mind). This also entails moving Data.Monoid into the standard. > I think the 'naming issue' that you mention highlights the need for better > use of type classes in the prelude. The major issue with typeclasses for things like special-purpose containers is that they almost inevitably wind up requiring multiparameter type classes with functional dependencies, or they need type families. This then runs afoul of the fact that since neither one is better than the other for all usecases, neither one seems to be drifting any closer to standardization. -Edward ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 proposing alternatives with no net effect?) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 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 > of text or on a sequence of bytes). > > - Specify operations on such an abstract String/Text type. > Personally, I think the standard shouldn't specify too many operations > over such a type to not limit implementors' freedom too much. > > - Integrate the rest of the standard library with this new abstract > type. This, I think, is actually the hardest part. > > I think most here agree that the main advantage of the current > definition is only pedagogical. Even then Strings are often built in > a very inefficient way by using ++ instead of ShowS + function > composition (which actually is a builder on its own). I don't really > think that having an abstract type is such a big problem for teaching. > You can do string processing by doing (pack . myfunction . unpack) > which is fine for this purpose. Once students are comfortable with > using higher-order functions, you can tell them to use the more > optimised Text-specific combinators. Builders are also a very nice > application of monoids. > > The larger problem for the Prelude would be that you can no longer use > the list functions on String/Text. This mainly leads to an issue with > naming things (e.g., length for lists and length for strings). > Similarly, file functions like readFile probably shouldn't return Text > but ByteStrings. But that would mean making ByteString part of the > Prelude as well. So I'm not too sure on these particular issues. > > On 23 March 2012 19:30, 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. > > > > 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 lets the user learn about induction, and > > encourages a "Haskelly" programming style, where you aren't mucking about > > with indices and Builders everywhere, which is frankly very difficult to > use > > when building Text. If you cons or append to build up a Text fragment, > > frankly you're doing it wrong. > > > > 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. Showing parsing through pattern matching on strings makes a very > > powerful tool, its harder to show that with Text. > > > > But even when taking apart Text, the choice of UTF16 internally makes it > > pretty much a worst case for many string manipulation purposes. (e.g. > > slicing has to spend linear time scanning the string) due to the > existence > > of codepoints outside of plane 0. > > > > The major benefits of Text come from FFI opportunities, but even there if > > you dig into its internals it has to copy out of the array to talk to > > foreign functions because it lives in unpinned memory unlike ByteString. > > > > The workarounds for these limitations all require access to the > internals, > > so a Text proposed in an implementation-agnostic manner is less than > useful, > > and one supplied with a rigid set of implementation choices seems to > > fossilize the current design. > > > > All of these things make me lean towards a position that it is premature > to > > push Text as the one true text representation. > > > > That I am very sympathetic to the position that the standard should > ensure > > that there are Text equivalents for all of the exposed string operations, > > like read, show, etc, and the various IO primitives, so that a user who > is > > savvy to all of these concerns has everything he needs to make his code > > perform well. > > > > Sent from my iPad > > > > On Mar 23, 2012, at 1:32 PM, Brandon Allbery > wrote: > > > > 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. > > > > -- > > brandon s allbery > allber...@gmail.com > > wandering unix systems administrator (available) (412) 475-9364vm/sms > > > > > > ___ > > Haskell-prime mailing list > > Haskell-prime@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-prime > > > > > > -- > Push the envelope.
Re: String != [Char]
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 operations on such an abstract String/Text type. Personally, I think the standard shouldn't specify too many operations over such a type to not limit implementors' freedom too much. - Integrate the rest of the standard library with this new abstract type. This, I think, is actually the hardest part. I think most here agree that the main advantage of the current definition is only pedagogical. Even then Strings are often built in a very inefficient way by using ++ instead of ShowS + function composition (which actually is a builder on its own). I don't really think that having an abstract type is such a big problem for teaching. You can do string processing by doing (pack . myfunction . unpack) which is fine for this purpose. Once students are comfortable with using higher-order functions, you can tell them to use the more optimised Text-specific combinators. Builders are also a very nice application of monoids. The larger problem for the Prelude would be that you can no longer use the list functions on String/Text. This mainly leads to an issue with naming things (e.g., length for lists and length for strings). Similarly, file functions like readFile probably shouldn't return Text but ByteStrings. But that would mean making ByteString part of the Prelude as well. So I'm not too sure on these particular issues. On 23 March 2012 19:30, 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. > > 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 lets the user learn about induction, and > encourages a "Haskelly" programming style, where you aren't mucking about > with indices and Builders everywhere, which is frankly very difficult to use > when building Text. If you cons or append to build up a Text fragment, > frankly you're doing it wrong. > > 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. Showing parsing through pattern matching on strings makes a very > powerful tool, its harder to show that with Text. > > But even when taking apart Text, the choice of UTF16 internally makes it > pretty much a worst case for many string manipulation purposes. (e.g. > slicing has to spend linear time scanning the string) due to the existence > of codepoints outside of plane 0. > > The major benefits of Text come from FFI opportunities, but even there if > you dig into its internals it has to copy out of the array to talk to > foreign functions because it lives in unpinned memory unlike ByteString. > > The workarounds for these limitations all require access to the internals, > so a Text proposed in an implementation-agnostic manner is less than useful, > and one supplied with a rigid set of implementation choices seems to > fossilize the current design. > > All of these things make me lean towards a position that it is premature to > push Text as the one true text representation. > > That I am very sympathetic to the position that the standard should ensure > that there are Text equivalents for all of the exposed string operations, > like read, show, etc, and the various IO primitives, so that a user who is > savvy to all of these concerns has everything he needs to make his code > perform well. > > Sent from my iPad > > On Mar 23, 2012, at 1:32 PM, Brandon Allbery wrote: > > 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. > > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > -- Push the envelope. Watch it bend. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 lets the user learn about induction, and encourages a "Haskelly" programming style, where you aren't mucking about with indices and Builders everywhere, which is frankly very difficult to use when building Text. If you cons or append to build up a Text fragment, frankly you're doing it wrong. 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. Showing parsing through pattern matching on strings makes a very powerful tool, its harder to show that with Text. But even when taking apart Text, the choice of UTF16 internally makes it pretty much a worst case for many string manipulation purposes. (e.g. slicing has to spend linear time scanning the string) due to the existence of codepoints outside of plane 0. The major benefits of Text come from FFI opportunities, but even there if you dig into its internals it has to copy out of the array to talk to foreign functions because it lives in unpinned memory unlike ByteString. The workarounds for these limitations all require access to the internals, so a Text proposed in an implementation-agnostic manner is less than useful, and one supplied with a rigid set of implementation choices seems to fossilize the current design. All of these things make me lean towards a position that it is premature to push Text as the one true text representation. That I am very sympathetic to the position that the standard should ensure that there are Text equivalents for all of the exposed string operations, like read, show, etc, and the various IO primitives, so that a user who is savvy to all of these concerns has everything he needs to make his code perform well. Sent from my iPad On Mar 23, 2012, at 1:32 PM, Brandon Allbery wrote: > 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. > > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
> 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. Actually, inlining is a already a big problem with Text https://github.com/bos/text/issues/19 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
>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 "deprecating" String. Text is good for many use-cases, but it has very different* asymptotic* behavior for many operations, and cannot serve as a one-size-fits-all replacement for String. I am less strongly against adding Text to the standard, but mostly because I am leery in that it brings a lot of language specification baggage and risks making attempts to explore the design space around Text harder. (e.g. Jasper's GSoC project this last year to investigate using UTF-8 encoded Data.Text would have been a much harder sell if Text was codified in the language standard!) Text has a remarkably (necessarily) large API and for the first time, as far as I can see, the specification would be largely requiring users to use qualified imports to access everything inside of it, which complicates the language standard from a pedagogical standpoint. Isn't it enough that it is part of the platform? -Edward ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 deprecated. > I'm in favour of this. In fact, I'm not sure if I would even deprecate String. I think just adding Text or something Text-like to the standard would be a good step towards encouraging libraries to use it as their first choice. It might, however, be wise to first adopt GHC's OverloadedStrings proposal so that the syntax for using string alternatives is more convenient. I'm inclined to start slow and small: OverloadedStrings is already in use, and makes sense with overloaded numeric literals that we already have, so I think it's reasonable to push for including that in the standard. I don't think that blessing any other string type is going to be very successful *without* OverloadedStrings, and I think that Duncan is right that we want to introduce a new type before removing the old one. 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. With regards to a general string API, I don't think a typeclass is the correct solution (except for string literals); my view is that things like ListLike may be practical but are awkward to use, and ambiguity problems only make things more upsetting. I think we should just take the abstract Text type and API, and leave implementors to do whatever they want behind that. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 comparisons to
Perl 6 is not going to help move the discussion along!
On Fri, Mar 23, 2012 at 6:33 AM, Christian Siefkes
wrote:
> 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 break many codebases (we shouldn't hope to apply all of
>> list's syntax to this string type) should we apply it alone or wait
>> until we have more other codebase-breakers to apply ?
>
> I very much hope that the Haskell committee will never ever accept a
> proposal that "will break many codebases"! That's what ruined Perl 6 und
> Python 3, and quite unnecessarily so.
>
> Even if I a future Haskell standard defines String as something that doesn't
> have to be implemented as a list of Char, it still would have to behave as
> if it was [Char] for most practical purposes (except performance-wise, of
> course!). That's necessary for compatibility. Or String could just be
> complemented with an additional standardized Text type, as Greg suggested.
>
> Best regards
> Christian
>
> --
> |--- Dr. Christian Siefkes --- christ...@siefkes.net ---
> | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
> | Peer Production Everywhere: http://peerconomy.org/wiki/
> |-- OpenPGP Key ID: 0x346452D8 --
> Just so that nobody takes his guess for the full truth, here's my standing
> on "keeping control", in 2 words (three?):
> I won't.
> -- Linus Torvalds, The Tanenbaum-Torvalds Debate
>
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 all of list's syntax to this string type) should we apply it alone or wait until we have more other codebase-breakers to apply ? I would expect the following steps: 1. Define what operations should be supported by String, that is, define a String API, possibly including thoughts on performance, formal specification, tests, benchmarks, ... 2. Convince all Haskell implementations to provide an implementation of the String API outside the Prelude, as an additional module (in the base package?). That implementation can be based on [Char] or something else. 3. Convince all string-like-packages on Hackage to provide exactly the String API in a separate module, so these packages are now drop-in replacements for the String implementations from step 2 above. At this point, we haven't touched the Prelude, but we have a blessed String API with multiple implementations. So applications can opt-in to use that String API instead of the Prelude-based [Char]. This allows us to: 4. Convince packages on Hackage to use the type String (from step 2) instead of Prelude-based [Char]; or to use the StringLike class instead of a concrete string type. 5. Refine the String API according to experience. And finally, we can: 6. Change Prelude.String to be the type from step 2 above. My hope is that because of steps 2 and 3, the investment from step 1 starts to pay off long before we reach step 6. Tillmann ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 break many codebases (we shouldn't hope to apply all of > list's syntax to this string type) should we apply it alone or wait > until we have more other codebase-breakers to apply ? I very much hope that the Haskell committee will never ever accept a proposal that "will break many codebases"! That's what ruined Perl 6 und Python 3, and quite unnecessarily so. Even if I a future Haskell standard defines String as something that doesn't have to be implemented as a list of Char, it still would have to behave as if it was [Char] for most practical purposes (except performance-wise, of course!). That's necessary for compatibility. Or String could just be complemented with an additional standardized Text type, as Greg suggested. Best regards Christian -- |--- Dr. Christian Siefkes --- christ...@siefkes.net --- | Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/ |Peer Production Everywhere: http://peerconomy.org/wiki/ |-- OpenPGP Key ID: 0x346452D8 -- Just so that nobody takes his guess for the full truth, here's my standing on "keeping control", in 2 words (three?): I won't. -- Linus Torvalds, The Tanenbaum-Torvalds Debate signature.asc Description: OpenPGP digital signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 David wrote: > 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 of thought and work >> is needed to ensure it can be implemented as smoothly as possible. It >> does seem though that everyone thinks it is a good proposal. > > Sorry for the misunderstanding, but when you said that someone should > take this proposal up and help make sure it gets in the next batch, I > believed you thought we could take this proposal as is. Deeply sorry > for my error. > 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 all of > list's syntax to this string type) should we apply it alone or wait > until we have more other codebase-breakers to apply ? > > -- > ARJANEN Loïc Jean David > http://luigiscorner.wordpress.com > --- > "Computer science is no more about computers than astronomy is about > telescopes, biology is about microscopes, or chemistry is about > beakers and test tubes. Science is not about tools. It is about how we > use them, and what we find out when we do." > Michael R. Fellows and Ian Parberry > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
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 of thought and work > is needed to ensure it can be implemented as smoothly as possible. It > does seem though that everyone thinks it is a good proposal. Sorry for the misunderstanding, but when you said that someone should take this proposal up and help make sure it gets in the next batch, I believed you thought we could take this proposal as is. Deeply sorry for my error. 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 all of list's syntax to this string type) should we apply it alone or wait until we have more other codebase-breakers to apply ? -- ARJANEN Loïc Jean David http://luigiscorner.wordpress.com --- "Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do." Michael R. Fellows and Ian Parberry ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
