> 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.
> 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]
> 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!
> 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.
"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:
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?
U+093b is still in the BMP. By the way, what text encodings for source files are supported by GHC? Escaping everything isn't fun.
And I am not sold on lens-regex-pcre documentation; "anything that works in PCRE will work" comes across as very dismissive.
What string-like types are supported? What version of PCRE or PCRE2 does it use?
I'm sorry, I don't know what that means. If you have a specific character you'd like me to try then please tell me what it is. My Unicode expertise is quite limited.
> I am not sold on lens-regex-pcre documentation
Nor me. It seems to leave a lot to be desired. In fact, I don't see the point of this lens approach to regex.
> "anything that works in PCRE will work" comes across as very dismissive
Noted, thanks, and apologies. That was not my intention. I was trying to make a statement of fact in response to your question.
> By the way, what text encodings for source files are supported by GHC?
UTF-8 I think. For example, pasting that character into GHC yields:
It uses https://hackage.haskell.org/package/pcre-light , which seems to link with the system version. So it depends on what you install. With Nix, it will be part of your system expression, of course.
Either hackernews or autocorrect ate the p, it was supposed to be \p{L} which is a unicode character class.
As the other comment mentioned pcre-compatible Regex are a standard, though the pcre spec isn't super readable. There are some projects that have more readable docs like mariadb and PHP, but it doesn't really make sense to repeat the spec in library docs https://www.php.net/manual/en/regexp.reference.unicode.php
There are libraries for pcre2 or gnu regex syntax with the same API if you prefer those
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.