5 ms·

> why would you restrict yourself to Haskell? It's not bleeding edge any more. I'm not using Haskell because it's bleeding edge. I use it because it is advanc

> why would you restrict yourself to Haskell? It's not bleeding edge any more. I'm not using Haskell because it's bleeding edge. I use it because it is advanced enough and practical enough. It's at a good balanced spot now to do practical things while tapping into some of the advances in programming language theory. The compiler and the build system have gotten a lot more stable over the past several years. The libraries for most production-type activities have gotten a lot more mature. And I get all of the above plus strong type safety and composability, which helps me maintain applications in a way that I find satisfactory. For someone who aims to be pragmatic with a hint of scholarliness, Haskell is great.

iso8859-1 2y ago
> The compiler and the build system have gotten a lot more stable over the past several years. GHC2021 promises backwards compatibility, but it includes ill-specified extensions like ScopedTypeVariables. TypeAbstractions were just added, and they do the same thing, but differently.[0] It hasn't even been decided yet which extensions are stable[1], yet GHC2021 still promises compatibility in future compiler versions. So either, you'll have GHC retain inferior semantics because of backwards compatibility, or multiple ways of doing the same thing. GHC2024 goes even further and includes extensions that are even more unstable, like DataKinds. Another sign of instability is the fact that GHC 9.4 is still the recommended[2] release even though there are three newer 'stable' GHCs. I don't know of other languages where the recommendation is so far behind! GHC 9.4.1 is from Aug 2022. It was the same situation with Cabal, it took forever to move beyond Cabal 3.6 because the subsequent releases had bugs.[3] [0]: https://serokell.io/blog/ghc-dependent-types-in-haskell-3 https://serokell.io/blog/ghc-dependent-types-in-haskell-3 [1]: https://github.com/ghc-proposals/ghc-proposals/pull/669 https://github.com/ghc-proposals/ghc-proposals/pull/669 [2]: https://github.com/haskell/ghcup-metadata/issues/220 https://github.com/haskell/ghcup-metadata/issues/220 [3]: https://github.com/haskell/ghcup-metadata/issues/40 https://github.com/haskell/ghcup-metadata/issues/40
- deleted 2y ago
  [deleted]
- tome 2y ago
  > GHC2024 goes even further and includes extensions that are even more unstable, like DataKinds. But DataKinds is not stable. It's one of the most stable extensions possible! The link you provided even says it's stable: https://github.com/telser/ghc-proposals/blob/initial-extension-categorization/proposals/0000-initial-extension-categorization.md#211-stable-extensions https://github.com/telser/ghc-proposals/blob/initial-extensi... > It hasn't even been decided yet which extensions are stable It's essentially known, but it's not formally agreed. The fact that this proposal exists is evidence of that! > GHC2021 still promises compatibility in future compiler versions. So either, you'll have GHC retain inferior semantics because of backwards compatibility, or multiple ways of doing the same thing. GHC2021 will always provide ScopedTypeVariables. A future edition will probably provide TypeAbstractions instead. Being able to make progress to the default language like this is the point of having language editions!
  - tome 2y ago
    > But DataKinds is not stable I mean "not unstable"
HelloNurse 2y ago
> The libraries for most production-type activities have gotten a lot more mature. Can you provide an example of a "mature" way to match a regular expression with Unicode character classes or download a file over HTTPS?
- Tarean 2y ago
  For Regex I like lens-regex-pcre > import Control.Regex.Lens.Text > "Foo, bar" ^.. [regex|\p{L}+|] . match ["Foo", "bar"] > "Foo, bar" & [regex|\p{L}+|] . ix 1 . match %~ T.intersperse '-' . T.toUpper "Foo, B-A-R" For web requests wreq has a nice interface. The openssl bindings come from a different library so it does need an extra config line, the wreq docs have this example: import OpenSSL.Session (context) import Network.HTTP.Client.OpenSSL let opts = defaults & manager .~ Left (opensslManagerSettings context) withOpenSSL $ getWith opts "https://httpbin.org/get" There are native Haskell tls implementations that you could plug into the manager config. But openssl is probably the more mature option.
  - HelloNurse 2y ago
    You are matching ASCII letters? Cute. What about Unicode character classes like \p{Spacing_Combining_Mark} and non-BMP characters? Can you translate the examples at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... to Haskell? This Control.Regex.Lens.Text library doesn't seem to believe in documenting the supported syntax, options, etc.
    - tome 2y ago
      "Cute" comes across as very dismissive. I'm not sure if you intended that. lens-regex-pcre is just a wrapper around PCRE, so anything that works in PCRE will work, for example, from your Mozilla reference: ghci> "California rolls $6.99\nCrunchy rolls $8.49\nShrimp tempura $10.99" ^.. [regex|\p{Sc}\s*[\d.,]+|] . match ["$6.99","$8.49","$10.99"] "Spacing combining mark" seems to be "Mc" so this works: https://unicode.org/reports/tr18/#General_Category_Property https://unicode.org/reports/tr18/#General_Category_Property ghci> "foo bar \x093b baz" ^.. [regex|\p{Mc}|] . match ["\2363"] (U+093b is a spacing combining mark, according to https://graphemica.com/categories/spacing-combining-mark https://graphemica.com/categories/spacing-combining-mark) I think in general that Haskellers would probably move to parser combinators in preference to regex when things get this complicated. I mean, who wants to read "\p{Sc}\s*[\d.,]+" in any case?

iso8859-1 2y ago

> The compiler and the build system have gotten a lot more stable over the past several years. GHC2021 promises backwards compatibility, but it includes ill-specified extensions like ScopedTypeVariables. TypeAbstractions were just added, and they do the same thing, but differently.[0] It hasn't even been decided yet which extensions are stable[1], yet GHC2021 still promises compatibility in future compiler versions. So either, you'll have GHC retain inferior semantics because of backwards compatibility, or multiple ways of doing the same thing. GHC2024 goes even further and includes extensions that are even more unstable, like DataKinds. Another sign of instability is the fact that GHC 9.4 is still the recommended[2] release even though there are three newer 'stable' GHCs. I don't know of other languages where the recommendation is so far behind! GHC 9.4.1 is from Aug 2022. It was the same situation with Cabal, it took forever to move beyond Cabal 3.6 because the subsequent releases had bugs.[3] [0]: https://serokell.io/blog/ghc-dependent-types-in-haskell-3 https://serokell.io/blog/ghc-dependent-types-in-haskell-3 [1]: https://github.com/ghc-proposals/ghc-proposals/pull/669 https://github.com/ghc-proposals/ghc-proposals/pull/669 [2]: https://github.com/haskell/ghcup-metadata/issues/220 https://github.com/haskell/ghcup-metadata/issues/220 [3]: https://github.com/haskell/ghcup-metadata/issues/40 https://github.com/haskell/ghcup-metadata/issues/40

deleted 2y ago
[deleted]
tome 2y ago
> GHC2024 goes even further and includes extensions that are even more unstable, like DataKinds. But DataKinds is not stable. It's one of the most stable extensions possible! The link you provided even says it's stable: https://github.com/telser/ghc-proposals/blob/initial-extension-categorization/proposals/0000-initial-extension-categorization.md#211-stable-extensions https://github.com/telser/ghc-proposals/blob/initial-extensi... > It hasn't even been decided yet which extensions are stable It's essentially known, but it's not formally agreed. The fact that this proposal exists is evidence of that! > GHC2021 still promises compatibility in future compiler versions. So either, you'll have GHC retain inferior semantics because of backwards compatibility, or multiple ways of doing the same thing. GHC2021 will always provide ScopedTypeVariables. A future edition will probably provide TypeAbstractions instead. Being able to make progress to the default language like this is the point of having language editions!
- tome 2y ago
  > But DataKinds is not stable I mean "not unstable"

HelloNurse 2y ago

> The libraries for most production-type activities have gotten a lot more mature. Can you provide an example of a "mature" way to match a regular expression with Unicode character classes or download a file over HTTPS?

Tarean 2y ago
For Regex I like lens-regex-pcre > import Control.Regex.Lens.Text > "Foo, bar" ^.. [regex|\p{L}+|] . match ["Foo", "bar"] > "Foo, bar" & [regex|\p{L}+|] . ix 1 . match %~ T.intersperse '-' . T.toUpper "Foo, B-A-R" For web requests wreq has a nice interface. The openssl bindings come from a different library so it does need an extra config line, the wreq docs have this example: import OpenSSL.Session (context) import Network.HTTP.Client.OpenSSL let opts = defaults & manager .~ Left (opensslManagerSettings context) withOpenSSL $ getWith opts "https://httpbin.org/get" There are native Haskell tls implementations that you could plug into the manager config. But openssl is probably the more mature option.
- HelloNurse 2y ago
  You are matching ASCII letters? Cute. What about Unicode character classes like \p{Spacing_Combining_Mark} and non-BMP characters? Can you translate the examples at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... to Haskell? This Control.Regex.Lens.Text library doesn't seem to believe in documenting the supported syntax, options, etc.
  - tome 2y ago
    "Cute" comes across as very dismissive. I'm not sure if you intended that. lens-regex-pcre is just a wrapper around PCRE, so anything that works in PCRE will work, for example, from your Mozilla reference: ghci> "California rolls $6.99\nCrunchy rolls $8.49\nShrimp tempura $10.99" ^.. [regex|\p{Sc}\s*[\d.,]+|] . match ["$6.99","$8.49","$10.99"] "Spacing combining mark" seems to be "Mc" so this works: https://unicode.org/reports/tr18/#General_Category_Property https://unicode.org/reports/tr18/#General_Category_Property ghci> "foo bar \x093b baz" ^.. [regex|\p{Mc}|] . match ["\2363"] (U+093b is a spacing combining mark, according to https://graphemica.com/categories/spacing-combining-mark https://graphemica.com/categories/spacing-combining-mark) I think in general that Haskellers would probably move to parser combinators in preference to regex when things get this complicated. I mean, who wants to read "\p{Sc}\s*[\d.,]+" in any case?