Comments on: What’s in a text API? http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/ Bryan O'Sullivan's blog Wed, 08 Feb 2012 06:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Sean http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-240201 Sean Mon, 20 Jul 2009 12:18:13 +0000 http://www.serpentine.com/blog/?p=397#comment-240201 I've gotten the impression that <a href="http://hackage.haskell.org/package/xformat" rel="nofollow">xformat</a> is unsuitable for i18n from multiple people now. I am very interested in improving it. As <a href="http://splonderzoek.blogspot.com/2009/06/rfc-extensible-typed-scanf-and-printf.html" rel="nofollow">I wrote</a>, this is really to get something out there for comments, not as a final implementation. How can it be improved? Or, if you prefer, how can we do type-safe, extensible i18n formatting in Haskell? Please contact me if you'd like to start a conversation about this. (I prefer email, but anything's fine.) I’ve gotten the impression that xformat is unsuitable for i18n from multiple people now. I am very interested in improving it. As I wrote, this is really to get something out there for comments, not as a final implementation. How can it be improved? Or, if you prefer, how can we do type-safe, extensible i18n formatting in Haskell?

Please contact me if you’d like to start a conversation about this. (I prefer email, but anything’s fine.)

]]> By: Christopher Lewis http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237531 Christopher Lewis Thu, 02 Jul 2009 02:22:19 +0000 http://www.serpentine.com/blog/?p=397#comment-237531 I share your frustrations regarding lots of little libraries and how this impacts a developer's ability to quickly locate and use the functionality they need. I have frequently experienced this frustration when using other community library management platforms similar to Hackage. When it comes to Haskell, however, I suffer from some tension on this subject. One of the beauties of a strongly-typed functional language like Haskell are the possibilities it offers a developer to structure and combine different APIs. So, to a certain extent, I view the proliferation of little, <i>interoperable</i> libraries on Hackage as one of the unique advantages of Haskell. Is it possible that there's a more desirable middle ground between lots of little packages and few or fewer larger packages? For example, do we need more structure in the current set of Hierarchical packages, allowing for the creation of what, for lack of a better term, I will call "super" packages that "collect" logically related functionality from many smaller packages? (Just to be clear, I'm not suggesting any form of extension to Haskell as a language, but additional organization layered over the packages offered on Hackage.) I share your frustrations regarding lots of little libraries and how this impacts a developer’s ability to quickly locate and use the functionality they need. I have frequently experienced this frustration when using other community library management platforms similar to Hackage. When it comes to Haskell, however, I suffer from some tension on this subject.

One of the beauties of a strongly-typed functional language like Haskell are the possibilities it offers a developer to structure and combine different APIs. So, to a certain extent, I view the proliferation of little, interoperable libraries on Hackage as one of the unique advantages of Haskell.

Is it possible that there’s a more desirable middle ground between lots of little packages and few or fewer larger packages? For example, do we need more structure in the current set of Hierarchical packages, allowing for the creation of what, for lack of a better term, I will call “super” packages that “collect” logically related functionality from many smaller packages? (Just to be clear, I’m not suggesting any form of extension to Haskell as a language, but additional organization layered over the packages offered on Hackage.)

]]> By: Bryan O'Sullivan http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237326 Bryan O'Sullivan Tue, 30 Jun 2009 16:30:57 +0000 http://www.serpentine.com/blog/?p=397#comment-237326 I love posting stuff before bed! Lots to respond to. Magnus, I wish there was a nice operator for the Monoid class's mappend function. That would nicely solve the append notation problem for a huge family of types. For now, there's nothing appealing :-( Eelco, I did see Seán's posting about typed formatting, and while it's cute, it has the severe problem of being unsuitable for i18n. Nicolas, thanks for reminding me of Data.List.Split. It's a richer API than I think is necessary (it edges into Parsec territory), but a slimmed down version would be good to use as a basis. Justin, the existing Data.Text API provides toUpper and friends over text, which behave correctly according to Unicode case folding rules. As for finding a way to get the extended API ported to strings and bytestrings, I don't have a dog in that fight. I don't think that either String or ByteString is an appropriate type to use for text manipulation, so I'm not going to make any efforts there. I love posting stuff before bed! Lots to respond to.

Magnus, I wish there was a nice operator for the Monoid class’s mappend function. That would nicely solve the append notation problem for a huge family of types. For now, there’s nothing appealing :-(

Eelco, I did see Seán’s posting about typed formatting, and while it’s cute, it has the severe problem of being unsuitable for i18n.

Nicolas, thanks for reminding me of Data.List.Split. It’s a richer API than I think is necessary (it edges into Parsec territory), but a slimmed down version would be good to use as a basis.

Justin, the existing Data.Text API provides toUpper and friends over text, which behave correctly according to Unicode case folding rules.

As for finding a way to get the extended API ported to strings and bytestrings, I don’t have a dog in that fight. I don’t think that either String or ByteString is an appropriate type to use for text manipulation, so I’m not going to make any efforts there.

]]> By: Justin Bailey http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237322 Justin Bailey Tue, 30 Jun 2009 15:51:05 +0000 http://www.serpentine.com/blog/?p=397#comment-237322 I would love to see string oriented operations like toUpper, toLower, and trim. isInfixOf and intercalate are examples of *worst* *function* *name* *ever*! I'm excited to see what you come up with, but will it be easy to use over multiple list-like representations? E.g. strings, bytestring, and text? I would love to see string oriented operations like toUpper, toLower, and trim. isInfixOf and intercalate are examples of *worst* *function* *name* *ever*!

I’m excited to see what you come up with, but will it be easy to use over multiple list-like representations? E.g. strings, bytestring, and text?

]]> By: Nicolas Pouillard http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237310 Nicolas Pouillard Tue, 30 Jun 2009 14:43:56 +0000 http://www.serpentine.com/blog/?p=397#comment-237310 About splitting, switching to Text -> Text -> [Text] won't suffice. Having a look to Data.List.Split may be a good idea. Moreover splitting on a regexp is very common in string processing. About splitting, switching to Text -> Text -> [Text] won’t suffice. Having a look to Data.List.Split may be a good idea. Moreover splitting on a regexp is very common in string processing.

]]> By: Eelco http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237285 Eelco Tue, 30 Jun 2009 10:06:23 +0000 http://www.serpentine.com/blog/?p=397#comment-237285 Very nice summary! I'm looking forward to your work. Have you seen http://splonderzoek.blogspot.com/2009/06/rfc-extensible-typed-scanf-and-printf.html BTW? It's a recent attempt to create a better formatting (and parsing) library. Very nice summary! I’m looking forward to your work. Have you seen http://splonderzoek.blogspot.com/2009/06/rfc-extensible-typed-scanf-and-printf.html BTW? It’s a recent attempt to create a better formatting (and parsing) library.

]]> By: Magnus http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237262 Magnus Tue, 30 Jun 2009 08:01:27 +0000 http://www.serpentine.com/blog/?p=397#comment-237262 Ah, yes, I should have mentioned that I use ++ on [Char]. It'd be nice to have a similar operator in Text, append is long! Ah, yes, I should have mentioned that I use ++ on [Char]. It’d be nice to have a similar operator in Text, append is long!

]]> By: Magnus http://www.serpentine.com/blog/2009/06/30/python-and-haskell-text-apis-compare/comment-page-1/#comment-237256 Magnus Tue, 30 Jun 2009 07:58:38 +0000 http://www.serpentine.com/blog/?p=397#comment-237256 I often use ++ instead of append. I often use ++ instead of append.

]]>