Jest sobie w Haskellu funkcja zip :: [a] -> [b] -> [(a, b)]. Dziś zrozumiałem że może być ona polimorficzna, jako funkcja dla Applicative, tzn
polymorphicZip :: Applicative f => f a -> f b -> f (a, b)
polymorphicZip = liftA2 (\ a b -> (a,b))
Nie jestem pewien czy dobrze napisałem implementację, ale mam nadzieję że sygnatura mówi wszystko :) Pytanie jak nazwać taką funkcję? W Scalaz nazywa się ona tuple2, a w Catsach product. Zna ktoś może lepszą nazwę?
Product to chyba dobra nazwa. Acz bardzo przeciazona. A przez to chyba juz nie taka dobra?
Na pewno polymorficZip jest bez sensu bo zip jest przeciez polimofirczny.
Swoja droga w ZIO to jest po prostu .zip :D
Ale korzystasz z hoogle?
Bo mówi mi, że jest raka funkcja i nazywa sie pairADefault. Nazwa jest gupia, ale jest.
Wytrzeźwiałem, sprawdziłem dla trzech argumentów i się zdegustowałem. I teraz jestem zdegustowaną istotą:
Jest TypeClassa Zip w Data.NonEmpty.Class Apbo nawet cały zbiór TypeClass Zip, Zip3, Zip4 w ClassyPrelude
zip :: Zip f => f a -> f b -> f (a, b)
zip3 :: Zip f => f a -> f b -> f c -> f (a, b, c)
zip4 :: Zip f => f a -> f b -> f c -> f d -> f (a, b, c, d)
są też odpowiednie metody zipWith:
zipWith :: (a -> b -> c) -> f a -> f b -> f c
zipWith3 :: Zip f => (a -> b -> c -> d) -> f a -> f b -> f c -> f d
zipWith4 :: Zip f => (a -> b -> c -> d -> e) -> f a -> f b -> f c -> f d -> f e
Jak na to patrzę to zipWith jest lepszą nazwą na liftA2, czyli w heirarchi dziedziczenia między Funktorem a Aplikatywą powinien być jeszcze Zip (Zip to Aplikatywa bez metody pure :D ).
Co ciekawe w ClassyPrelude Aplikatywa nie dziedziczy z Zip, może coś źle rozumiem
Update to ejst bardziej pokręcone. Czytam [Programowanie Funkcyjne dla Śmiertelników] i tam Aplikatywa dziedziczy z Apply, ale Zip jest gdzieś bokiem
stivens napisał(a):
Na pewno polymorficZip jest bez sensu bo zip jest przeciez polimofirczny.
Może zip jest polimorficzne w zio (strasznie mało dokumentacji jest), ale w base (bibliotece standardowej Haskella) zip nie jest polimorficzny. Ogólnie to standardowa base wygląda tak jakby najpierw wyklepali wszystkie funkcje dla List a potem dopiero robili ich polimorficzne wersje, np
++ to konkretna konkatenacja dla List, <> polimorficzna konkatenacja dla Semigrupymap to konkretne mapowanie dla List, fmap polimorficzne mapowanie dla FunktorazipWith to konkretne zipowanie z mapowaniem dla List, liftA2 to polimorficzne zipowanie z mapowaniem dla Aplikatywyzip to konkretne zipowanie do krotki dla List, a brzydkie pairADefault to polimorficzne zipowanie do krotki dla AplikatywyCała biblioteka standardowa Haskella nadaje się do przepisania :D
zip :: [a] -> [b] -> [(a, b)] jak to nie jest polimorficzne wzgledem a i b to ja nie wiem :)
Ja z kontekstu rozumiem, ze Tobie to chodzi o polimorfizm wzgledem "kontenera" no ale no :)
stivens napisał(a):
zip :: [a] -> [b] -> [(a, b)] jak to nie jest polimorficzne wzgledem a i b to ja nie wiem :)
Względem a b jest, ale ja był chciał też żeby nie było zależne od listy :P
Czyli zip :: Applicative f => f a -> f b -> f (a, b) albo zip :: Zip f => f a -> f b -> f (a, b).
Wtedy mogę tej funkcji użyć też do zipowania Eitherów albo Option/Maybe
Wracam po długim czasie z przemyślaniami. Jak już myślałem że ogarnąłem temat to teraz trafiam na MonadZip z metodą mzip :: m a -> m b -> m (a, b) . Metoda jest ciekawa z dwóch powodów:
zipM gdzie M oznacza że chodzi o monadęm na poczatku. Więc sa dwie konwencje, albo małe m na poczatku, albo duże M na końcu. Ale pi'rdolnik XD )A co do przemyśleń to mam wrażenie coraz bardziej że Haskell to taki Legacy Language do którego wpada jakiś doktorant jak trzeba napisać jakąś pracę, implementuje swój pomysł jako paczkę i wrzuca to społeczności.Przez co mam cztery różne zipy i jak potrzebuję zipa który działa dla Applicative (taka słabsza wersja monady) to musze sam go sobie napisać. Może też go wydam jako paczkę?