Cross-compilare OCaml a Javascript

[tajmone]

Ho rispulciato i miei appunti riguardo la cross-compilazione a Javascript. E, indovina un po'? OCaml è supportato.

Questa è la lista di compilatori OCaml 2 Javascript che ho trovato sul Wiki di CoffeeScript:

Name	Description
Ocamljs	OCaml to JS.
O’Browser	OCaml bytecode interpreter in JS.
Js_of_ocaml	OCaml bytecode to JS compiler.
Bucklescript	OCaml to readable JS

Il potenziale direi che è enorme!

Dato che Polygen non si appoggia a librerie esterne, basterebbero poche modifiche per trasformarlo in una libreria, sia binaria che Javascript.

Una volta compilatolo in Javascript, esistono ulteriori strumenti per poterne fare sia un pacchetto NPM per Node.js (come libreria e come struemnto CLI 100% javascript), sia per renderlo utilizzabile tramite browser:

• https://en.wikipedia.org/wiki/Asm.js
• https://en.wikipedia.org/wiki/Emscripten
• https://en.wikipedia.org/wiki/WebAssembly

Questa presentazione a slide è un ottimo punto di partenza:

• http://kripken.github.io/mloc_emscripten_talk/#/

Che ne pensi?

Io credo che riscrivere tutto da zero sia un mega lavoraccio, perlopiù inutile. La cross-compilazione mi pare più fattibile e consentirebbe di preservare il codice attuale.

[tajmone]

Sto spulciando i progetti OCaml menzionati nella tabella; alcuni sono veri e propri backend per il compilatore OCaml, altri sono virtual machine che consentono di far girare codice oggetto OCaml nel browser.

Sono davvero progetti fantastici, e sembra potrebbero essere in grado di compilare PolyGen senza ulteriori strumenti.

Javascript è un linguaggio davvero performante, ed è molto più universale che non il Java (a mio avviso). Una volta creata la libreria di PolyGen (libPolyGen?), con una sua API, il resto sarebbe una passeggiata.

Le librerie statiche e dinamiche potrebbero essere incorporate in applicazioni di vario tipo, il che consentirebbe anche di implementare una nuova interfaccia da riga di comando in qualsiasi linguaggio (che so, per aggiungere nuove opzioni e funzionalità, filtri, ecc.).

La libreria in Javascript consentirebbe di utilizzare Polygen direttamente nel browser, buttando il carico di lavoro sul client e scavalcando la necessità di un server, interfacciamenti CGI, PHP, ecc. La pagina web si limiterebbe a fornire il sorgente javascript, ma siccome le risorse di calcolo passano al client, anche se 10.000 utenti in contemporanea continuassero a generare testo il server non consumerebbe alcuna risorsa.

[alvisespano]

Di riscriverlo in javascript non ci penso neanche, perché non solo è un lavoraccio, ma javascript è anche il peggior linguaggio della storia dell'umanità e non ho intenzione di riscrivere un programma pulito, piccolo ed intricato come il polygen in un linguaggio unsound. La cross compilazione mi sembra la strada migliore, perché si sporca le mani al posto mio. Oltre ad essere brutto javascript è anche lento, non è vero che è performante se paragonato ai linguaggi con un compilatore di qualità (come C per esempio, o lo stesso OCaml). Tuttavia - forse tu intendi - è performante in senso relativo, cioè, per essere un pastrocchio interpretato che gira su un browser, javascript non è male; e negli ultimi anni ha anche fatto qualche piccolo passo in avanti, sia in termini di performance dei jit sia in termini di scelte di language design. Morale della favola: della performance possiamo tranquillamente fregarcene, perché anche se è un ordine di grandezza più lento di OCaml, ci va bene lo stesso. Inoltre, Javascript cross-compilato da OCaml è talmente una buona notizia che si può sorvolare sopra l'orrore e sopra la performance; performance che tra l'alto impatta solo sul client in ogni caso. Il problema è che la cross-compilazione è una bestia strana: bisogna scoprire COSA cross-compila e cosa produce in output. Se è in grado di tradurre i binding a top level di un modulo ML in binding a top level js allora direi che è meglio prima scrivere la libreria in OCaml (così il refactoring ed il testing è fatto in linguaggio migliore) e poi la tradurla; se invece è in grado di tradurre applicazioni stand alone (cioè aventi un main o una qualche forma di entrypoint) allora sarà necessario mettere mano al sorgente js generato dal traduttore per rendere il tutto una libreria con una API -- e questo potrebbe essere una passeggiata come no, dipende da quanto traduce e da quali sono le limitazioni che impone (perché sicuramente non compilerà ogni singola feature di OCaml, poiché alcune di esse non sono nemmeno esprimibili in js, se non riproducendole tramite un qualche pattern js in cui si perde probabilmente il fulcro stesso della feature). Infine, vorrei pensare ad ultimo aspetto: la mantenibilità. Ora come ora Polygen è 1 programma standalone scritto in 1 linguaggio (OCaml). Se domani mattina lo cross-compiliamo in js, al netto del problema di refactoring di cui sopra, sarà necessario mantenere 2 distinte versioni del sorgente. Naturalmente potremmo dismettere totalmente la versione OCaml e tenere solamente quella js, ma questo significa che in futuro, qualunque siano gli interventi e gli upgrade al polygen, dovranno essere implementati (a) in javascript, (b) intervenendo in un sorgente che non è stato scritto da un umano e (c) usando un linguaggio pessimo e per niente adatto alla scrittura di software di genere term manipulation. Questi sono 3 grossi ostacoli che possono essere sormontati tutti contemporaneamente se invece prediamo un'altra strada: continuiamo a mantenere ed upgradare polygen in OCaml ed introduciamo la cross-compilazione nel processo di building. In altre parole: il programma (o libreria, o entrambi) rimane bello e pulito, scritto in OCaml, e la versione js la generiamo a build time ogni volta. Per poter imboccare questa strada però occorre sapere come funziona la cross compilazione ml-to-js. E quindi ritorniamo al punto di prima. C'è anche un'altra alternativa, sebbene meno realistica: potrei riscrivere Polygen in Haskell e mantenerlo per sempre in Haskell in ogni sua forma, libreria o altro, appoggiandomi al nutrito kit di strumenti per il web di cui Haskell e la sua community oggi dispongono. Haskell è un linguaggio che non fa rimpiangere OCaml (anzi, il suo type system è ancora più potente) e gode anche di ottima salute, quanto a ecosistema e supporto. Anche Scala sarebbe un candidato con grossomodo le medesime proprietà di Haskell. Si tratta però di lavoro più profondo ed intenso di quel "consolidamento" che avevo/avevamo in mente: per quanto polygen sia già scritto, tradurlo a mano significa riscriverlo secondo le convenzioni, gli standard e gli stili imposti dal linguaggio target. E non possiamo scendere a compromessi di qualità, altrimenti viene meno l'obiettivo primario del porting, ovvero la mantenibilità. Sì, insomma, è un lavoraccio pure questo alla fine della festa, e non sono sicuro di aver voglia :P Il giorno 16 gennaio 2018 15:22, Tristano Ajmone <notifications@github.com> ha scritto:

…

Sto spulciando i progetti OCaml menzionati nella tabella; alcuni sono veri e propri backend per il compilatore OCaml, altri sono virtual machine che consentono di far girare codice oggetto OCaml nel browser. Sono davvero progetti fantastici, e sembra potrebbero essere in grado di compilare PolyGen senza ulteriori strumenti. Javascript è un linguaggio davvero performante, ed è molto più universale che non il Java (a mio avviso). Una volta creata la libreria di PolyGen ( libPolyGen?), con una sua API, il resto sarebbe una passeggiata. Le librerie statiche e dinamiche potrebbero essere incorporate in applicazioni di vario tipo, il che consentirebbe anche di implementare una nuova interfaccia da riga di comando in qualsiasi linguaggio (che so, per aggiungere nuove opzioni e funzionalità, filtri, ecc.). La libreria in Javascript consentirebbe di utilizzare Polygen direttamente nel browser, buttando il carico di lavoro sul client e scavalcando la necessità di un server, interfacciamenti CGI, PHP, ecc. La pagina web si limiterebbe a fornire il sorgente javascript, ma siccome le risorse di calcolo passano al client, anche se 10.000 utenti in contemporanea continuassero a generare testo il server non consumerebbe alcuna risorsa. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACcZxg67rMzP-wWyTxLNnSgug-5z5IDUks5tLLCWgaJpZM4Rf0md> .

[alvisespano]

A scanso di equivoci: non voglio demolire la tua proposta, non fraintendermi :) Non amo i linguaggi come js, però le indagini che hai fatto hanno individuato una opportunità notevole con il cross compilatore ml-to-js. Se dobbiamo usare js a scatola chiusa (cioè solo come backend di una traduzione), allora ok, altrimenti potrebbe essere più complicato di quanto non sembri. Ma vale la pena informarsi meglio, appena ho tempo lo farò. Il giorno 16 gennaio 2018 16:56, Alvise Spanò <spano.alvise@gmail.com> ha scritto:

…

Di riscriverlo in javascript non ci penso neanche, perché non solo è un lavoraccio, ma javascript è anche il peggior linguaggio della storia dell'umanità e non ho intenzione di riscrivere un programma pulito, piccolo ed intricato come il polygen in un linguaggio unsound. La cross compilazione mi sembra la strada migliore, perché si sporca le mani al posto mio. Oltre ad essere brutto javascript è anche lento, non è vero che è performante se paragonato ai linguaggi con un compilatore di qualità (come C per esempio, o lo stesso OCaml). Tuttavia - forse tu intendi - è performante in senso relativo, cioè, per essere un pastrocchio interpretato che gira su un browser, javascript non è male; e negli ultimi anni ha anche fatto qualche piccolo passo in avanti, sia in termini di performance dei jit sia in termini di scelte di language design. Morale della favola: della performance possiamo tranquillamente fregarcene, perché anche se è un ordine di grandezza più lento di OCaml, ci va bene lo stesso. Inoltre, Javascript cross-compilato da OCaml è talmente una buona notizia che si può sorvolare sopra l'orrore e sopra la performance; performance che tra l'alto impatta solo sul client in ogni caso. Il problema è che la cross-compilazione è una bestia strana: bisogna scoprire COSA cross-compila e cosa produce in output. Se è in grado di tradurre i binding a top level di un modulo ML in binding a top level js allora direi che è meglio prima scrivere la libreria in OCaml (così il refactoring ed il testing è fatto in linguaggio migliore) e poi la tradurla; se invece è in grado di tradurre applicazioni stand alone (cioè aventi un main o una qualche forma di entrypoint) allora sarà necessario mettere mano al sorgente js generato dal traduttore per rendere il tutto una libreria con una API -- e questo potrebbe essere una passeggiata come no, dipende da quanto traduce e da quali sono le limitazioni che impone (perché sicuramente non compilerà ogni singola feature di OCaml, poiché alcune di esse non sono nemmeno esprimibili in js, se non riproducendole tramite un qualche pattern js in cui si perde probabilmente il fulcro stesso della feature). Infine, vorrei pensare ad ultimo aspetto: la mantenibilità. Ora come ora Polygen è 1 programma standalone scritto in 1 linguaggio (OCaml). Se domani mattina lo cross-compiliamo in js, al netto del problema di refactoring di cui sopra, sarà necessario mantenere 2 distinte versioni del sorgente. Naturalmente potremmo dismettere totalmente la versione OCaml e tenere solamente quella js, ma questo significa che in futuro, qualunque siano gli interventi e gli upgrade al polygen, dovranno essere implementati (a) in javascript, (b) intervenendo in un sorgente che non è stato scritto da un umano e (c) usando un linguaggio pessimo e per niente adatto alla scrittura di software di genere term manipulation. Questi sono 3 grossi ostacoli che possono essere sormontati tutti contemporaneamente se invece prediamo un'altra strada: continuiamo a mantenere ed upgradare polygen in OCaml ed introduciamo la cross-compilazione nel processo di building. In altre parole: il programma (o libreria, o entrambi) rimane bello e pulito, scritto in OCaml, e la versione js la generiamo a build time ogni volta. Per poter imboccare questa strada però occorre sapere come funziona la cross compilazione ml-to-js. E quindi ritorniamo al punto di prima. C'è anche un'altra alternativa, sebbene meno realistica: potrei riscrivere Polygen in Haskell e mantenerlo per sempre in Haskell in ogni sua forma, libreria o altro, appoggiandomi al nutrito kit di strumenti per il web di cui Haskell e la sua community oggi dispongono. Haskell è un linguaggio che non fa rimpiangere OCaml (anzi, il suo type system è ancora più potente) e gode anche di ottima salute, quanto a ecosistema e supporto. Anche Scala sarebbe un candidato con grossomodo le medesime proprietà di Haskell. Si tratta però di lavoro più profondo ed intenso di quel "consolidamento" che avevo/avevamo in mente: per quanto polygen sia già scritto, tradurlo a mano significa riscriverlo secondo le convenzioni, gli standard e gli stili imposti dal linguaggio target. E non possiamo scendere a compromessi di qualità, altrimenti viene meno l'obiettivo primario del porting, ovvero la mantenibilità. Sì, insomma, è un lavoraccio pure questo alla fine della festa, e non sono sicuro di aver voglia :P Il giorno 16 gennaio 2018 15:22, Tristano Ajmone ***@***.*** > ha scritto: > Sto spulciando i progetti OCaml menzionati nella tabella; alcuni sono > veri e propri backend per il compilatore OCaml, altri sono virtual machine > che consentono di far girare codice oggetto OCaml nel browser. > > Sono davvero progetti fantastici, e sembra potrebbero essere in grado di > compilare PolyGen senza ulteriori strumenti. > > Javascript è un linguaggio davvero performante, ed è molto più universale > che non il Java (a mio avviso). Una volta creata la libreria di PolyGen ( > libPolyGen?), con una sua API, il resto sarebbe una passeggiata. > > Le librerie statiche e dinamiche potrebbero essere incorporate in > applicazioni di vario tipo, il che consentirebbe anche di implementare una > nuova interfaccia da riga di comando in qualsiasi linguaggio (che so, per > aggiungere nuove opzioni e funzionalità, filtri, ecc.). > > La libreria in Javascript consentirebbe di utilizzare Polygen > direttamente nel browser, buttando il carico di lavoro sul client e > scavalcando la necessità di un server, interfacciamenti CGI, PHP, ecc. La > pagina web si limiterebbe a fornire il sorgente javascript, ma siccome le > risorse di calcolo passano al client, anche se 10.000 utenti in > contemporanea continuassero a generare testo il server non consumerebbe > alcuna risorsa. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#10 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACcZxg67rMzP-wWyTxLNnSgug-5z5IDUks5tLLCWgaJpZM4Rf0md> > . >

[tajmone]

Di riscriverlo in javascript non ci penso neanche

scusa, devo essermi espresso male. Intendevo solo la cross compilazione di PolyGen come libreria accessible tramite API.

Il problema è che la cross-compilazione è una bestia strana: bisogna
scoprire COSA cross-compila e cosa produce in output. Se è in grado di
tradurre i binding a top level di un modulo ML in binding a top level js
allora direi che è meglio prima scrivere la libreria in OCaml (così il
refactoring ed il testing è fatto in linguaggio migliore) e poi la
tradurla;

Da quel che ho visto vi sono vari approcci e opzioni in merito. Credo che la libreria OCaml sia comunque la strada migliore, e forse la più facile. Purtoppo OCaml fa parte di una categoria di linguaggi che non conosco, e non posso esserti d'aiuto, se no mi ci sarei buttato. Presumo che, come nella maggior parte dei linguagi high level, si tratti solo di separare il codice che interfaccia alla riga di comando (opzioni, e varie) dal "motore" vero e proprio (lexer, parser, etc) così da rendere accessibili le funzioni di quest'ultimo tramite una API pubblica.

Infine, vorrei pensare ad ultimo aspetto: la mantenibilità ... se invece prediamo un'altra strada: continuiamo a mantenere ed upgradare polygen in OCaml ed introduciamo la cross-compilazione nel processo di building. In altre
parole: il programma (o libreria, o entrambi) rimane bello e pulito,
scritto in OCaml, e la versione js la generiamo a build time ogni volta.

Concordo, questa strada è l'unica che ha senso (e che avevo in mente). Inoltre, il gioco vale la candela solo questa cross compilazione è davvero un processo che si riduce a creare un makefile e che di tutto il resto si occupino i tool delegati al compito (se così non fosse, la mantenibilità andrebber a farsi friggere).

Per poter imboccare questa strada però occorre sapere come funziona la
cross compilazione ml-to-js. E quindi ritorniamo al punto di prima.

Su questo posso documentarmi, ma non conscendo OCaml al primo intoppo entrerò nel panico. Comunque, posso installare il tutto su Linux e sperimentare. Di sicuro la docuemntazione non manca per questi progetti, che sono poi solo tre dato che uno dei quattro linkati è fermo da otto anni.

C'è anche un'altra alternativa, sebbene meno realistica: potrei riscrivere
Polygen in Haskell

Haskell sta andando alla grande. Ma vale la pena riscrivere ciò che già funziona bene? Voglio dire, ok OCaml è un po' stagnante come linguaggio al momento, ma ho visto che è comunque mantenuto attivamente in alcune sue versioni, e su Linux sarà comunque disponibile senza problemi.

Si tratta però di lavoro più profondo ed intenso di quel "consolidamento"
che avevo/avevamo in mente: per quanto polygen sia già scritto, tradurlo a
mano significa riscriverlo secondo le convenzioni, gli standard e gli stili
imposti dal linguaggio target. E non possiamo scendere a compromessi di
qualità, altrimenti viene meno l'obiettivo primario del porting, ovvero la
mantenibilità.
Sì, insomma, è un lavoraccio pure questo alla fine della festa, e non sono
sicuro di aver voglia :P

Direi che è uno sbattone troppo grosso. Un conto è se tu avessi voglia di scrivere una nuova versione da zero, finalizzata al supporto Unicode e altre cose — fregandotene della retrocompatibiltà con le gramamtiche attuali. Ma se è solo per far girare le grammatich odierne, non ne vale la pena. In fondo si trova sempre il modo di farlo funzionare anche su Windows (che su Linux il problema neanche si pone). Secondo me anche fra 10 anni lo si potrà eseguire su un PC, d'altronde esistono emulatori MS-DOS, ZX-81, C-64, e via dicendo.

Però, se la cross compilazione fosse davvero roba da un click e vai ... allora sarebbe una manna dal cielo. E, poter far girare PolyGen nel browser sarebbe fico, e non credo che l'utente medio (con 8 o più Core a 64 bit) noterebbe problemi o differenze di performance.

javascript è anche il peggior linguaggio della storia
dell'umanità ... un linguaggio unsound.

Oltre ad essere brutto javascript è anche lento, non è vero che è
performante se paragonato ai linguaggi con un compilatore di qualità (come
C per esempio, o lo stesso OCaml).

Allo stato attuale, un sorgente Java o C# cross-compilato in Javascript girà a metà delle velocità rispetto a programma nel linguaggio originale. Direi che non è male. Però paragonare il linguaggio di scripting a uno studiato per la compilazione binaria non ha molto senso. Python è 13 volte più lento di un programma in C compilato, ma è normale che sia così dato che è un programma di scripting no?

Tuttavia - forse tu intendi - è performante in senso relativo, cioè, per
essere un pastrocchio interpretato che gira su un browser, javascript non è
male;

Io non uso Javascript nel browser, lo uso sul PC tramite Node.js, quindi senza limiti di sand-boxing. La cattiva reputazione di Javascript è dovuta al fatto che molti l'associano alla sandbox Javascript dei browser (e all'orribile periodo delle "guerre dei browser" e le scadenti implementazioni di Javascript).

Fuori dal browser, Javascript è performante per via delle funzioni asincrone. Chiaramente, come ogni linguaggio, vi sono settori in cui spicca di più e quelli in cui spicca di meno. Però un pastrocchio?

[alvisespano]

Quando dico che Javascript è un brutto linguaggio non intendo dire che non sia utile o usabile - ogni giorno lo usano milioni di persone e mezzo web è scritto in javascript.
Quello che intendo è questo: ci sono linguaggi inventati da linguaggisti, con l'avvallo della comunità scientifica, che implementano o inventano feature avanzate studiate in letteratura; altri invece non sono così.
Non è una forma di snobismo: la scienza dei linguaggi esiste, come esista la fisica delle particelle o la chimica organica, e ha raggiunto dei traguardi nel corso dei decenni. I linguaggi che sono figli di questa scienza hanno delle proprietà matematiche importanti, come ad esempio la soundness, che garantisce che un programma che compila allora funziona per forza - nel senso che non può fallire a runtime, non nel senso che fa quello che il programmatore aveva in mente.
Tutti gli ML sono di questa categoria: sono linguaggi "d'autore", nel senso che sono fatti da scienziati (informatici) che hanno dedicato la vita allo studio ed all'approfondimento della materia.
Haskell è il top in questo: creato a mantenuto sostanzialmente dalla comunità scientifica dei linguaggi.
Idem per OCaml, Scala, Clojure ed altri (anche Lw, che ho creato io nel mio piccolo, appartiene a questa famiglia).

E poi ci sono i linguaggi cosiddetti industriali: C, C++, Java, C#, PHP, Python, Javascript, Go, Rush, Ruby e moltissimi altri, impossibili da elencare tutti.
Sono linguaggi più semplici, fatti da persone in gamba naturalmente, ma non sono conosciuti per le loro feature ground-breaking o per aver portato avanti il carretto della scienza dei linguaggi.
Sono linguaggi pratici, utili, usatissimi - che io stesso conosco molto bene e che uso regolarmente - ma non sono "il top possibile ad oggi" perché ignorano tutta una serie di traguardi formali raggiunti in letteratura e propongono feature arcinote.

Non c'è nessuna forma di aristocrazia in ciò che dico: è un dato di fatto riconosciuto da chi si occupa di linguaggi. Rispetto moltissimo l'autore di Python, per esempio, ma Python è un linguaggio che non ha inventato niente - solamente fa bene cose note da 40 anni. Ci sono dei meriti anche in questo, non fraintendermi! Ma OCaml o Haskell sono tutto un altro livello: è come paragonare una Lamborghini con una Golf.

Fatta questa doverosa premessa, Javascript è un linguaggetto creato da "mestieranti", non da esperti di linguaggi, che è diventato standard globale suo malgrado. Spesso accade che diventino mainstream cose che non dovrebbero diventarlo, dal punto di vista qualitativo. In particolare Javascript è un pasticcio di linguaggio: è totalmente unsound ed è molto facile scrivere programmi che non funzionano perché le scelte di design sono orientate allo scrivere poco ed al deploy facile, non alla robustezza, alla sicurezza del codice ed al riuso.

[iacopy]

E vai di Haskell allora :)

[pdonadeo]

Forse potreste essere interessati al mio fork di Polygen: gira nel browser come libreria che, per ora, espone solo una funzione di generazione.

https://github.com/pdonadeo/Polygen

[tajmone]

@pdonadeo:

Forse potreste essere interessati al mio fork di Polygen: gira nel browser come libreria che, per ora, espone solo una funzione di generazione.

Grazie del link! Cercherò di aggiornare i vari Wiki per linkarlo, appena trovo il tempo.

[alvisespano]

Grazie! Molto carino! Funziona come una unica funzione con una grammatica come unico argomento?
Ricordo che tanti anni fa l'aveva fatta anche Zeff (l'amico che fece il sito polygen.org originale) tipo nel 2003, poi nel 2007, poi nel 2010 e di nuovo nel 2011, finché si è rotto i coglioni perché ogni anno cambiavano le tecnologie web e bisognava rifare il wrapper da capo :D
Cmq apprezzo molto! Me ne intendo poco, ma credo che oggi le tecnologie web siano un pochino più stabili e di vita semi-lunga, speriamo :)

[pdonadeo]

Sì è una unica funzione, esportata come Polygen.generate che ha come unico argomento una stringa con la grammatica.

Se interessa posso scrivere un minimo di documentazione su come compilare il progetto con un ambiente OCaml moderno. Penso che Polygen nel browser apra infinite possibilità :D

Questa è una micro demo.

cast-2021-02-13_14.59.15.mp4

[alvisespano]

Assolutamente Paolo! E' carinissimo e apre la porta, come dici tu, a infinite possibilità. Se hai voglia di scrivere un po' di doc, magari con la consulenza di @tajmone, sarebbe perfetto. Potremmo anche pensare di integrare il tuo wrapper web al polygen ufficiale, per esempio linkandolo ufficialmente e/o menzionandolo.

[tajmone]

Se hai voglia di scrivere un po' di doc, magari con la consulenza di @tajmone, sarebbe perfetto.

Concordo, la documentazione non è mai abbastanza né di intralcio, e sono disponibile.

Potremmo anche pensare di integrare il tuo wrapper web al polygen ufficiale, per esempio linkandolo ufficialmente e/o menzionandolo.

Non ho avuto modo di sbirciare ai sorgenti, quindi volevo capire: si tratta di una cross-compilazione da OCaml a JavaScript (WebASM, o simili)? In quel caso, si potrebbe pensare di aggiungerlo alla toolchain ufficiale, così le due applicazioni si aggiornano di pari passo.

Ma, anche se non fosse un caso di cross-compilazione, si potrebbe pensare di integrare la demo HTML (e quanto serve) nel repository ufficiale stesso, come esempio di utilizzo (specie, appunto, se buttiamo giù della documentazione).

Tra gli ovvi vantaggi, l'automazione dei test tramite servizi CI (GitHub Actions, Travis CI, Cilcle CI, o quant'altro) che potremmo eseguire a nostra discrezione ad ogni commit/PR, o prima di creare una nuova tagged release.