Podczas przetwarzania dużych ilości danych tekstowych zaleca się stosowanie Data.Text zamiast natywnych ciągów haskells. Sprawdź, gotowe. Ale co powiesz na wyrazy regularne? Czy jest dostępna biblioteka regex, specjalizująca się w Data.Text? O ile widzę, wszystkie biblioteki wyrażeń regularnych pracują nad natywnymi ciągami Haskella lub jeszcze gorszymi CStrings.Haskell: Wyrażenia regularne i dane.Teksty
Nie mam pojęcia o Haskell, ale czytanie documentation jest zawsze dobrym pomysłem bez względu na język programowania.
Aby korzystać z rozszerzoną i bardzo bogatej rodziny funkcji do pracy z tekstu Unicode (w tym normalizacji, wyrażeń regularnych, niestandardowe kodowanie, łamanie tekstu i ustawień regionalnych), patrz tekst-ICU pakiet: http://hackage.haskell.org/package/text-icu
dokładniej Data.Text.ICU.Regex
Powitanie wyjaśnienia na dole – m0skit0
Regular Expression and Ecosystem Haskell
Regeksy to narzędzie, które sprawia, że ludzie migrujący z innych języków oczekują jednego z narzędzi dostępnych w tym języku. W językach kompilowanych funkcje te mają raczej postać bibliotek takich jak PCRE. Języki skryptów często mają wbudowane Regexy bezpośrednio w język, ale pod maską interpreter używa jednej z tych samych bibliotek.
Istnieje ku temu dobry powód. Finite State Automata są dość tajemnicze, dość żmudne w implementacji i trudne do wydajnego działania. Po co wyważać koło?
Co jest nie tak z Haskellem? Cóż, te dobrze znane biblioteki działają na tablicach 8-bitowych słów zakończonych bajtem NUL - a mianowicie CString w nomenklaturze Haskella. Regularne ciągi w Haskell są listami Char. (całkiem dosłownie: type String = [Char]). To powoduje dwa problemy: 1) char jest pojedynczym znakiem Unicode, a nie 8-bitowym bajtem. (GHC zapisuje wewnętrznie jako UTF16) i 2) lista nie jest tablicą. Oznacza to, że jeśli chcemy robić Regex w Haskell, musimy albo przekonwertować nasz tekst na CStiring i wykonać obce połączenie na coś podobnego do PCRE, albo wdrożyć wydajne Finite State Automata i regex parser natively.
Konwersja Unicode na Ascii to operacja stratna i ryzykowna. Niektóre biblioteki przyjmują pewne założenia dotyczące łańcucha, nad którym pracują i wykonują konwersję, inne umożliwiają budowanie CString dla nich, dzięki czemu można dowiedzieć się, co zrobić, gdy w tekście trasy pojawi się ☃.
A więc co z Data.Text? Cóż, jest to przynajmniej tablica, ale wewnętrznie jest to tablica UTF16. Nadal można konwertować do 8-bitowego CStringa, ale nie z dużą wydajnością. Istnieje również możliwość użycia silnika regex obsługującego Unicode. International Components for Unicode (ICU) ma such a library i wiąże się z nim w pakiecie text-icu. Sam charakter Unicode oznacza, że ten pakiet jest mniej wydajny niż PCRE, więc niektórzy ludzie wolą nadal używać wiązań z tymi ostatnimi. Będziesz musiał zdecydować, jakie są twoje preferencje w oparciu o to, do czego używasz wyrażeń regularnych.
Należy pamiętać, że ze względu na łatwość tworzenia parserów (dosłownie tuziny pakietów) w Haskell, wyrażenia regularne nie są w rzeczywistości bardzo popularne w większości idiomatycznych kodów Haskella. Parsery są bardziej czytelne (nazywasz produkcje itp.), łatwiejsze do utrzymania i niekoniecznie są znacznie wolniejsze. – copumpkin
Czy próbowałeś Text.Regex.TDFA [http://hackage.haskell.org/package/regex-tdfa]? Uważam, że jest wystarczająco szybki, ale nie wiem, co oznacza * duża ilość * danych w twoim przypadku. Zgadzam się również z parserami @copumpkin takimi jak Text.Parsec, które są bardziej odpowiednie w większości sytuacji. –
w szczególności zobacz wersję tekstową: http://hackage.haskell.org/package/regex-tdfa-text – sclv