@gianluca.scacco sembra che non sia stato "portato"

per cui non puoi usarlo

e' Clojure-only praticamente

@richiardiandrea grazie. In effetti il messaggio di errore è chiaro.

giorn!

buongiorno a tutti

giorno

Puzzle del giorno: (transduce (map inc) - 0 (range 10)) 55 (invece di -55). Qualcuno vuole cimentarsi? 🙂

(completing -) :)

Devo veramente metterci "escluso @bronsa" tutte le volte? 🙂

non ho spiegato perche` pero`!

vero... ENIGMA

Leggevo questo ieri http://numba.pydata.org/numba-doc/dev/developer/architecture.html . Non sarebbe carino averlo in clj? Che sappia io c'e' solo qualche esperimento del 2014 in giro poi non se n'e' fatto piu' niente.

intendi clj -> llvm o altro?

piu' la parte di ottimizzazione. Se f e' annotata (ad esempio), il bytecode prodotto viene analizzato, i tipi estratti durante il primo utilizzo e una versione ottimizzata prodotta in automatico. La versione ottimizzata puo' essere su LLVM (come numba). Oppure il bytecode riscritto per la jvm.

e` piu` o meno quel che fa truffle/graal

https://en.wikipedia.org/wiki/Graal_(compiler)

servirebbe un'implementazione per clojure

mmmh, interessante, ci do un ocio

comunque Hotspot dovrebbe già fare quell'ottimizzazione IIRC

Anche se non metto i type hint? Perche' lo scopo sarebbe fare type inference

no, Hotspot non rimuove reflection

se ho capito quel che stai pensando, si può fare con invokedynamic

facciamo che se capisco cosa sto pensando ti faccio un fischio 🙂

quel docs su numba usa un'architettura affascinante per analizzare python vm (= bytecode), effettuare type inference e scrivere LLVM bytecode che viene utilizzato da quel punto in poi. La parte di type inference e' interessante, perche' mi permetterebbe di scrivere clj ottimizzato senza type hints. Tutto in teoria. Non sono sicuro che ci sia vantaggio ad usare LLVM VS bytecode ottimizzato per la JVM. non ho be presente come funziona invokedynamic. E' equivalente a riscrivere una porzione non ottimizzata del bytcode per chiamare l'overload corretto sui tipi?