4 ms·

1. I don't think they define too many specialized operators personally; Haskell's heritage is more "mathematical" than many other languages so it makes sense th

by Ixiaus 13y ago

1. I don't think they define too many specialized operators personally; Haskell's heritage is more "mathematical" than many other languages so it makes sense that many variables are single letters and operators are defined with symbols instead of reallyLongAndDescriptiveName. It's part of learning the idioms of the language. 2. They should never use the same symbol. As the parent said, if you want the generalized notion of a monoid then use that (<> or mappend), otherwise each library should not be conflating its instance of a TypeClass with other libraries' instances of a TypeClass - it is confusing and you end up with stuff like: import Some.Lib as L import Some.Other.Lib as OL (L.+) 2 3 (OL.+) "2" "3" vs. import Data.Monoid (Sum 2) <> (Sum 3) "2" <> "3" Which is inevitable for some libraries (Fay for example re-defines a lot of Prelude functions) and sometimes accidental; but it is confusing and bad design unless you define a way to generalize it (Monoids!). 5. Data.Aeson uses ByteStrings for the JSON serialization, when encoding/decoding you provide your own instance defining the Types (can be Text/String/ByteString) so I don't understand your gripe here; Text.Regex shouldn't be used for Data.Text, that's what this package is for: http://hackage.haskell.org/packages/archive/text-icu/0.6.3.5/doc/html/Data-Text-ICU-Regex.html http://hackage.haskell.org/packages/archive/text-icu/0.6.3.5...

bjourne 13y ago
When you want to encode and decode JSON data of unknown format then you need to use the encode and decode functions directly which operates on ByteStrings. You really don't want to create a new record for each possible kind of JSON data container you have. text-icu is an experimental 3rd party binding and doesn't work like pcre anyway. It's not something you would use over Haskell's standard library regexp support, so you still have to deal with X number of different string types.
- Ixiaus 13y ago
  True re: encoding or decoding; but it does make sense to me to keep it in ByteStrings as that is an efficient representation - from ByteStrings you can do what you want with it (convert it to Text). I personally haven't used the Text.ICU package but I know many, big, packages that retain the "experimental" flag. So that shouldn't necessarily deter usage; just because it's 3rd party doesn't mean it's bad either - many fundamental components of the Haskell ecosystem are 3rd party! There are also many libraries that implement bindings - I don't necessarily see why that is a bad thing either; obviously a pure Haskell approach would be nice but in some cases it does defeat the purpose to reinvent something. What I do agree with you on, though, is the lack of clarity in what should be used. I think the Haskell Platform is a good start in that direction but there are few docs written on "this is how you deal with strings and unicode in Haskell and all the libraries we recommend for it". The good news is, this language has the capability to serve both the research needs of academics and the practical needs of implementers; so uncovering this stuff is very good.

by Ixiaus 13y ago

bjourne 13y ago

When you want to encode and decode JSON data of unknown format then you need to use the encode and decode functions directly which operates on ByteStrings. You really don't want to create a new record for each possible kind of JSON data container you have. text-icu is an experimental 3rd party binding and doesn't work like pcre anyway. It's not something you would use over Haskell's standard library regexp support, so you still have to deal with X number of different string types.

Ixiaus 13y ago
True re: encoding or decoding; but it does make sense to me to keep it in ByteStrings as that is an efficient representation - from ByteStrings you can do what you want with it (convert it to Text). I personally haven't used the Text.ICU package but I know many, big, packages that retain the "experimental" flag. So that shouldn't necessarily deter usage; just because it's 3rd party doesn't mean it's bad either - many fundamental components of the Haskell ecosystem are 3rd party! There are also many libraries that implement bindings - I don't necessarily see why that is a bad thing either; obviously a pure Haskell approach would be nice but in some cases it does defeat the purpose to reinvent something. What I do agree with you on, though, is the lack of clarity in what should be used. I think the Haskell Platform is a good start in that direction but there are few docs written on "this is how you deal with strings and unicode in Haskell and all the libraries we recommend for it". The good news is, this language has the capability to serve both the research needs of academics and the practical needs of implementers; so uncovering this stuff is very good.