Jiří Knesl: To nevím, ale neměl by být problém k tomu napsat wrapper, pokud se Clojure spustí nad JVM: * Scala se kompiluje do celkem přirozeného bytecode. Výjimkou jsou speciální znaky v identifikátorech, například znak '=' se přeloží jako "$eq", '#' se přeloží jako "$hash" apod. Metoda s názvem "someValue_=" (tedy běžný setter ve Scale) se přeloží jako "someValue_$eq". Bližší představu lze získat pomocí nástroje javap. * Interoperabilita Clojure s JVM tu je: http://clojure.org/java_interop * Nezkoumal jsem to moc, ale možná i Clojure bude umět Scalovské konvence se speciálními znaky ($eq, $hash, $plus, ...) a půjde to ještě přirozeněji. * Lambda funkce jsou ve Scale scala.FunctionN, kde N je počet parametrů. Tuto část wrapperu bych ale psal spíše ve Scale. Obecně všechny Scalové traity (možná bude pár výjimek) je lepší implementovat ve Scale. Nebo můžeme udělat abstract class AbstractFunction2[-T1, -T2, +R] extends Function2[T1, T2, R] a dědit z AbstractFunction2. * Možná bude potřeba řešit implicití konverze, které Scala používá, ale Slicku se to nejspíš netýká.
Rozhodně by to *šlo*, JVM konec konců mluví jedním jazykem, ale nejsem si jistý jestli by to šlo *tak jednoduše*. SLICK se někde dost spoléhá na implicitní magii a to by se v Clojure, jak dynamickém jazyce, muselo nějak rafinovaně emulovat.
Já myslel, že právě Slick moc implicitní konverze nepotřebuje. Ty používá dost Squeryl, ale u Slicku jsem myslel, že by se bez nich obešel.
Pak bych je spíš řešil v tom wrapperu ručně nebo je nechal vyřešit Scalovým kompilátorem. Psát automatické konverze pro Clojure by byl overkill - možná pro programátora a celkem určitě pro CPU, protože Clojure by to muselo řešit dynamicky za běhu, ne při kompilaci.
Navíc v dynamickém jazyce tyto automatické konverze mohou fungovat jen omezeně (neznáš typy parametrů). To by na 95 % tady nebyl problém (vzlášť při volání Scalového kódu), ale je dobré s tím počítat.