Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 11-05-25 08:52 AM, Johan Tibell wrote: On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. You don't necessarily need spaces and dot to abstract over bytestrings and Unicode string types. They both implement IsString and Monoid classes, as well as operations null, length, isPrefixOf, take, and drop. That's sufficient to implement a generic parser that works on any input type supporting these operations (see [1] for example), though there is some performance cost. I don't see why a pretty-printer should be any more difficult. [1] http://hackage.haskell.org/package/incremental-parser ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 4:02 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 26 May 2011 08:49, wren ng thornton w...@freegeek.org wrote: On 5/25/11 1:03 PM, Bryan O'Sullivan wrote: On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. *shrug* this discussion on #haskell came about because lispy wanted to generate textual ByteStrings (using just ASCII) and would prefer not to have the overhead of Text. Actually, I am okay with Text. My application is translating GHC Core to other languages. I may have misrepresented my position on IRC. Oops. In the case of GHC Core, all the unicode bytes are z encoded [1] away so that I'm certain to just have ascii bytes, and I don't think performance will be an issue. Being able to choose between String and Text in the same library is nice. Once you add support for letting the user specify their choice of String or Text, does it really cost that much to add ByteString? I think there are some cases where ByteString might make sense. Take darcs patches. Darcs does it's best to be encoding agnostic about patch hunk data, yet the syntax surrounding the hunk data is just ascii compatible bytes. Last time I checked, ByteString was still used to store the patch hunks as just a blob of bytes. You end up passing that to some pretty printer code when serializing it, even though you're doing your best not to dictate the encoding. I know darcs has had a lot of important utf-8 changes since I looked at the hunk representation code so what I said above may no longer be the case. Admittedly it's a rare case. Jason [1] http://hackage.haskell.org/package/zenc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Policy for taking over a package on Hackage
With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I was thinking of doing so, and in such a case it would probably make the most amount of sense to actually then migrate the package back to the wl-pprint package instead of defining yet another package (and corresponding namespace), especially as I recalled from when I first started hacking on wl-pprint-text at the beginning of the year that the last (and only) upload had been in 2007 by Stefan O'Rear. As such, I was going to email Stefan and asked if he minded if I took over maintaining wl-pprint. However, when I went to the package page to get his email address, I saw that Otakar Smrz had released a new version about a month ago, and that the only change in the package that I could find was that OverlappingInstances was added to the .cabal file (which I thought wouldn't make a difference anyway). Now, for all I know, Otakar had already asked Stefan for permission to take over the package (I've CC'd both of them just in case). But even if he didn't, we don't officially have any policies set in place - especially ones that are enforced by requiring registering a package and specifying a maintainer - to indicate that such a thing shouldn't be done. Furthermore, if packages aren't announced then there's no way for people to know that there _is_ a new maintainer. This situation also arose last year [1], and was resolved by someone volunteering to take over a package. However, no formal policy was set in place (despite one being proposed). As such, I'd like to propose the following policy based upon the one Ben Millwood proposed last time on how to take over maintainership of a package that hasn't been updated for a while: 1. Email the current listed maintainer and wait a specified period of time (e.g. 2 weeks). 2. Email haskell-cafe, explicitly CC'ing maintainers of reverse dependencies (at least those that are themselves still active) and request permission to take over. This way, people who know the maintainer might point out that they are indeed still around, etc. 3. If no-one objects within another two weeks, announce that you have taken over maintainership with a new email (in case people are ignoring the previous thread). 4. Upload a point release of the previous package (assuming it follows the PVP) with yourself as the new maintainer (just to get it out there). Alternatively, if you already have a new version ready to go then upload that. Of course, having a policy like this is useless if there is no way to enforce it. Is it possible at the very least to have Hackage note when a new version of a package is uploaded with a new maintainer and require it to be approved by someone before it iis officially available? I think this would be the bare minimum (as opposed to requiring explicit logins on a per-package basis or some kind of signing) required for this kind of scheme to be effective. [1]: http://www.haskell.org/pipermail/haskell-cafe/2010-August/081353.html and http://www.haskell.org/pipermail/haskell-cafe/2010-August/082319.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 22:17, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. Such as? I'm _hopeless_ at making up names... ;-) Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators... Also, by clashes with Applicative, are you referring to empty and $ ? I'm not sure if a better name than empty can be found; as for $, maybe using pretty's notation of $$ and $+$ rather than $ and $$ ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
2011/5/25 Ivan Lazar Miljenovic ivan.miljeno...@gmail.com: On 25 May 2011 22:17, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. Such as? I'm _hopeless_ at making up names... ;-) Having a new package would require a new name and new module namespace, let alone thinking up new names for combinators... Also, by clashes with Applicative, are you referring to empty and $ ? I'm not sure if a better name than empty can be found; as for $, maybe using pretty's notation of $$ and $+$ rather than $ and $$ ? What about 'emptyDoc'? Moreover, if you are changing the names of combinators, then moving them away from Applicative and Arrow would be a good idea; i.e., don't use +, as it already used by ArrowPlus. Moreover, if you can make a Monoid instance such that `mappend` equals , you would also make the library compatible to a future introduction of () = mappend. best regards, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 22:52, Johan Tibell johan.tib...@gmail.com wrote: On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I'm a bit skeptical of using type classes to abstract over Unicode string types and byte sequence types. The only API shared by the two kind of types is that of a sequence. Things like dot , spaces, etc. don't make much sense on binary data. You must assume that the ByteString contains text in some encoding to make sense of such concepts. Well, using the Char8 version. I was thinking of a class looking something like: class (IsString s, Monoid (Builder s)) = Prettyable s where type Builder s toBuilder :: s - Builder s fromBuilder :: Builder s - s And then Doc now takes in a type parameter, which needs to be an instance of Prettyable. The IsString constraint is so that combinators like int and double can be defined via show (rather than have them being class-level methods), toBuilder is used to convert an actual s value to (Doc s) and fromBuilder is used for the final rendering at the end. The only other thing I can think of that _may_ need to be done on a class level is the allowable size lengths of values (Int64 for lazy ByteString and Text, and possibly just Int for convenience with String). Though if displayIO is going to be kept some kind of s - IO () method will also be needed, though arguably displayIO isn't that necessary. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 25 May 2011 23:23, Otakar Smrz otakar.s...@cmu.edu wrote: I took over the maintenance of wl-pprint since Stefan suggested it himself. I needed to include OverlappingInstances, because that was required to make better use of the library (there is a difference having this flag there, which is consistent with the GHC documentation on OverlappingInstances). I was not aware that I have to announce this. I thought people would know from checking Hackage that there is this maintainer change and a new version of the package. Sorry. The whole email wasn't aimed at you specifically: it's just that with Hackage's current infrastructure it's quite easy for someone to take over a package and possibly do something malicious with it (so the next time they do a cabal update they could inadvertently get a package with said malicious code). Especially if there's no announcement of the change, it's difficult to know that someone has indeed taken over maintaining a library, and thus they could keep addressing queries (or throwing blame) at someone known to be the maintainer of a package even if they didn't upload the latest version. Since I do not have any plans to develop wl-pprint further, I have no problem giving the maintainer's role to you or anyone interested. OK; if no-one has any objections I'll do so and make it class-based as I've discussed in the threads on -cafe (after considering name clashes with Applicative, etc.). PS: For the point 4 of your suggested rules, I think uploading a new version of a package if only the maintainer changes, rather than when there is some actual change to the library, is inappropriate. You could easily get package versions increasing without any code/documentation being actually improved or extended. By point release I meant incrementing the fourth digit, which is usually used to refer to bug-fixes. My aim with this was that the new maintainer could immediately make their mark so that people looking for a project's maintainer on the hackage page knew who to contact (rather than waiting for them to finish of their new improved version). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal: Add to the .cabal file the following optional field: Related-package: ACTION NAME VERSION Information - The first word is the ACTION and is one of: Replaces, Redesigns, Extends, or Alternative. - The second word is the NAME of the related package. - The third word is the VERSION of the related package. - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. There may be multiple Related-package entries specifying different packages and actions. Conceptually, the ACTION indicates: - Replaces: This package is intended as a newer replacement to use instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify). - Redesigns: This package is intended as a replacement for the older package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3. - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two. - Extends: This package uses the previous package and extends it with complementary functionality. For example, attoparsec-binary extends attoparsec. I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well. The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 5:01 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: With my wl-pprint-text package, Jason Dagit suggested to me on #haskell that it would make sense to make such a pretty-printer be class-based so that the same API could be used for String, ByteString, Text, etc. I don't think that's actually a good idea. The internals of your package will be a soggy mess, and the public APIs will be hard to follow. I'm also unclear on why you'd want to use something like wl-pprint for bytestrings at all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: On Wed, 25 May 2011 05:17:46 -0700, Stephen Tetley stephen.tet...@gmail.com wrote: Hi Ivan Forks are good, no? The Parsec experience has suggested to me at least, that new author's capping another author's work by bumping up to a major version, causes a significant difficulties even when the original author has gone. As for wl-pprint, it was a very tidy library in its original implementation - it's a pity it now has name clashes with Applicative. My feeling is that a new library in a new namespace with some attention to new combinator names would be better. At the risk of returning to a recurring theme that often comes up but never gets resolved satisfactorily, I'd like to make a cabal proposal: Add to the .cabal file the following optional field: Related-package: ACTION NAME VERSION Information - The first word is the ACTION and is one of: Replaces, Redesigns, Extends, or Alternative. - The second word is the NAME of the related package. - The third word is the VERSION of the related package. - Any additional text is information describing how the packages relate in descriptive terms and could be a multi-line paragraph like the existing Description: field. There may be multiple Related-package entries specifying different packages and actions. Conceptually, the ACTION indicates: - Replaces: This package is intended as a newer replacement to use instead of the older package. It intends to provide all the functionality of the existing package, although perhaps with API or dependency modifications and will probably evolve to provide additional functionality as well (this is probably what Ivan's new package would specify). - Redesigns: This package is intended as a replacement for the older package. It intends to provide similar functionality, but using a new approach and the API (and probably dependencies) is expected to have significant changes. An example of this would be Parsec2 and Parsec3. - Alternative: This package is a horizontal replacement for the other package providing the same type of functionality. The API or dependencies may be a bit different (e.g. mtl and transformers would be Alternatives of each other) but the overall intent of the package is the same. The Information should describe the difference between the two. - Extends: This package uses the previous package and extends it with complementary functionality. For example, attoparsec-binary extends attoparsec. I would suggest the ACTION be limited to known terms such as the above, whereas the Information is free-form for more clarification. The VERSION is important to know where the relationship was established, especially for a Replaces or Alternative type of package where the reference package continues to evolve as well. The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
Quoting Antoine Latter aslat...@gmail.com: On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. -KQ - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package. I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used. Antoine On May 25, 2011 12:50 PM, qu...@sparq.org wrote: Quoting Antoine Latter aslat...@gmail.com: On May 25, 2011 11:08 AM, KQ qu...@sparq.org wrote: The HackageDB could the provide this information in the description page of a package, and it could even automatically cross-reference and supplement the referred package descriptions, so that if you are looking at the Parsec2 page it will also show a section This package has a Redesign: parsec3. The redesign states: ...[Information]... This type of information can help people know what the alternatives are for various packages and a general understanding of the reason for the proliferation of packages (without having to search haskell-cafe and stack-overflow archives for some discussion that provided the justification/recommendations). Thoughts? The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. Antoine I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. -KQ - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 5/25/11 1:56 PM, Antoine Latter wrote: On May 25, 2011 12:50 PM,qu...@sparq.org wrote: Quoting Antoine Latteraslat...@gmail.com: The only thing I'd add would be the additional actions ReplacedBy, ExtendedBy and RedesignedBy. I was actually thinking that this was the part that HackageDB could do automatically on the page that the actionBy applied to. There should be enough information in the DB (somewhat like Roel's reverse dependencies work) and the alternative would be having to re-release a package (that you don't necessarily own) to add the actionBy field. I wanted the second set because I may want to establish the link even if I'm not the maintainer of the second package. I would imagine that the second set of actions would be otherwise identical, and the link would show up on either package regardless of which set of verbs was used. Exactly. Sometimes the new package designer may be unaware of the prior art, or may be too timid to declare obviating another's work. Also, allowing for both sides to declare the link can help to serve as verification of the relationship. If someone uploads the 'awesome' package which declares itself to replace everything on Hackage, should we just accept it at face value? Moreover, a feature like this new field would be useful for pruning the list of packages shown on the index, but do we want to allow the maintainer of package A to simply fiat that package B shouldn't be shown on the index anymore? We have a nice community, but security and validation are still good things to plan into the design. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 5/25/11 1:03 PM, Bryan O'Sullivan wrote: On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Policy for taking over a package on Hackage
On 26 May 2011 08:49, wren ng thornton w...@freegeek.org wrote: On 5/25/11 1:03 PM, Bryan O'Sullivan wrote: On Wed, May 25, 2011 at 5:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Well, using the Char8 version. Just because you *could* do that, it doesn't mean that you *should*. It's a bad idea to use bytestrings for manipulating text, yet the only plausible reason to have wl-pprint handle bytestrings is so that they can be used as text. It's worth highlighting that even with the Char8 version of ByteStrings you still run into encoding issues. Remember the days before Unicode came about? True, 8-bit encodings are often ASCII-compatible and therefore the representation of digits and whitespace are consistent regardless of (ASCII-compatible) encoding, but that's still just begging for issues. What are the semantics of the byte 0xA0 with respect to pretty-printing issues like linewraps? Are they consistent among all extant 8-bit encodings? What about bytes in 0x80..0x9F? What about 0x7F for that matter? I won't say that ByteStrings should never be used for text (there are plenty of programs whose use of text involves only whitespace splitting and moving around the resultant opaque blobs of memory). But at a bare minimum, the use of ByteStrings for encoding text needs to be done via newtype wrapper(s) which keep track of the encoding. Especially for typeclass instances. *shrug* this discussion on #haskell came about because lispy wanted to generate textual ByteStrings (using just ASCII) and would prefer not to have the overhead of Text. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
