Obecnie piszę trochę instalacji rurowej / attoparsec dla mojego małego projektu. Chcę, aby każdy parser dał potok, który czekaByteString wejście do parsera i daje dowolne przeanalizowane wartości (ponowne uruchomienie parsera). Bez obsługi błędów miałby więc typ podobny do tego

parserP :: Monad m => Parser a -> Pipe ByteString a m r

Teraz nie jestem pewien, co zrobić z błędami analizy. Moje obecne pomysły to:

aby dodać błędy do typu powrotu (tzn. zwrócić wartość wEither ParseError r a nie tylkor)wymagać od monady dostarczenia mechanizmu obsługi błędów (tj. wymagać od monady przejęcia rurociąguMonadError)zmusić monadę do dostarczenia mechanizmu błędu poprzez przejęcie ruryErrorT e m a dlakażdy monadmdodaj parametry, pozwalając użytkownikowi określić zachowanie (coś w stylu(ParseError -> P.Pipe ByteString a m r)i po prostu połącz się z tak dostarczoną rurą w przypadku błędu analizy)

Pierwsze rozwiązanie wydaje się niewłaściwe, ponieważ użycie typu powrotu potoku do obsługi błędów wydaje się raczej hackiem. Po pierwsze, sprawia, że ​​kompozycja z rurą jest brzydsza i wydaje się być bardziej lub mniej podporządkowana ostatecznemu rozwiązaniu (poza możliwością utraty zdolności pozwalania potoku niższego rzędu na odzyskanie po błędzie za pomocą tryAwait i zatrzymanie oczekiwania na wartości) ?).

Drugie rozwiązanie wydaje się błędne, choć nie mogę pojąć, dlaczego. Prawdopodobnie, ponieważ wymagałoby to (może?) Także przyjęcia parametru tłumaczącego ParseError na dowolny typ błędu, który ma monada (chyba że chcemy, aby monada zaimplementowałaMonadError ParseError, co wydaje się, że skutkowałoby to dużą księgowością). W końcu nie wydaje mi się, żeby pamiętałem, że widziałemMonadError wokół tego wszystkiego, co sugerowałoby, że istnieje problem z jego używaniem.

Trzecie rozwiązanie zadziałałoby w moim przypadku, ponieważ rura będzie częścią potoku z monadą określoną przez użytkownika (IO), która nie powinna troszczyć się o błędy parsowania (będzie analizować dane sieciowe w formacie przekazanym użytkownikowi) określony typ). Ale nie wydaje się to aż tak eleganckie i znowu (ewentualnie?) Spowoduje, że wiele książek będzie kiedyś używanych w jakimkolwiek innym kontekście.

Nie zastanawiałem się nad ostatecznym rozwiązaniem, ale wydaje się nieco zawiłe.

Byłbym wdzięczny za wszelkie przemyślenia w tej konkretnej sprawie (nie byłbym w ogóle zaskoczony, jeśli odejdę i stracę coś oczywistego) oraz za wszelkie (bardziej lub mniej istotne) odniesienia do dyskusji na temat obsługi błędów w rurach ( -core) / conduits / interatee itp

EDYCJA: Inną możliwością może być podjęcie działania monadycznego (zamiast pełnej rury), chociaż nie jestem do końca pewien, czy może uogólnić, wyspecjalizować, czy nawet być równoważny czwartej.