Transducerji v funkcijskih jezikih

ZaphodBB je 14. avg 2015 ob 18:27 izjavil:

Clojure, Lisp, Haskell - če hočeš širiti obzorja na programerskem področju.

Sam trenutno delam na tem, da zaštekam transducerje.

Kaj pa je tukaj tezkega? Koncno so implementiral kombiniranje operacij, kar je osnovni predpogoj, da funkcijsko programiranje neha smrdet.

Spura je 15. avg 2015 ob 12:08 izjavil:

ZaphodBB je 14. avg 2015 ob 18:27 izjavil:

Clojure, Lisp, Haskell - če hočeš širiti obzorja na programerskem področju.

Sam trenutno delam na tem, da zaštekam transducerje.

Kaj pa je tukaj tezkega? Koncno so implementiral kombiniranje operacij, kar je osnovni predpogoj, da funkcijsko programiranje neha smrdet.

no kompozitum funkcij ni nič novega. že nekaj desetletij. tu gre pa na prvi uč neko kombinacijo folda in kompozituma. pa še to v homoiconik jezikih drugje moraš isto stvar prevefrjat v compile timu.

drugac gre pa zato da ti ni treba kompozituma priredit tretji funkciji ampak jih namečeš kot parametre nad nekim seznamom. ne pršpra velik.

clojure sam to sebi niti ne pozna operatorjev. glede alokacij v objektnem pa ja. to drži. ampak kompozitum mapirat na nek fold, spet ni neki revolucionarnga. niti generalizacija.

Sem pogledal video o transducerjih pa moram rečt, da gre za zanimiv koncept, ne razumem pa, zakaj tak hype okoli tega. Meni izgleda vse skupaj kot posplošitev osnovnih gradnikov funkcijskega programiranja (map, fold, filter).

Map vzame neko funkcijo in jo izvede po vseh elementih seznama. Ampak "težava" je v tem, da je vhod in izhod seznam in tako se mora tudi map zavedati, kako sestavljati seznam. Mapping je kolikor razumem samo funkcija, ki dobi kot parameter tudi način kako sestavljati elemente (privzeto conj) in vrne tak map. Oz. zadeve lahko poljubno sestavljaš in šele na koncu rečeš ok, to bom zdaj uporabil nad seznami. No v bistvu je transducer malo bolj zakompliciran (več funkcij) zaradi raznih corner-casov, ampak sama ideja je pomoje uporaba funkcijskih paradigm nad "čemerkoli".

V "čistih" jezikih tipa Haskell je vse skupaj precej brezveze. Prvič zaradi lenobe, ki ti omogoča, da imaš neskončen seznam in torej niti ne rabiš streamov. Drugič pa zaradi tega, ker map lahko narediš na poljubnem funktorju oz. fold nad Foldable. V npr. Clojure (ali Scali) si pa predstavljam, da je vse skupaj uporabno, ker si želiš interoperabilnosti z obstoječo Java kodo in knjižnicami.

Back on topic, za branje priporočam:

http://learnyouahaskell.com/
http://learnyousomeerlang.com/

Ne, @fiction, v scali ni uporabno, ker imaš hierarhijo podatkovnih struktur. Naprimer vse podatkovne strukture, po katerih se lahko zapelješ, recimo List, Vector, Map, itd. extendajo Traversable, ... Če boš napisal transformacijo po Seq podatkovnem tipu, bo delovala po vseh zaporedjih.

Tako da so teli transducerji bolj muha programskega jezika Clojure (in verjetno še kakšnega) in zato nevredni, da bi zasedali prostor v mojih možganih. Hell, še wikipedija nima članka o njih.

def transform(a: Traversable[Int]) = a.filter(...).map(..).reduce(...)

transform(List(1, 2, 3))
transform(Vector(1,2,3))
transform(Map(1 -> "a", 2 -> "b").keys)

Če hočeš, da se izvedejo v enem sprehodu čez strukturo, enostavno uporabiš .view, .iterator ali pa .toStream.

Pač sprijazni se, da je to neka specifika jezika Clojure raje kot nekaj, kar bi bilo univerzalno uporabno, kot recimo monada, funktor, itd...