El analyse de mulang.js se come la pc

[asanzo]

¡HOLAAAaaa!

Esto es una especie de bug report/pregunta, porque todavía no sé si el problema somos nosotres. Estamos usando mulang.js, la última versión publicada (6.0.6).

Esto sucede al hacer mulang.astCode(elAst).customExpect(edl):

Me bloquea absolutamente la página por 3 o 4 segundos aunque lo ponga en un setTimeout. Nada es clickeable hasta que termine de ejecutar.

Sucede con cualquier ast y cualquier edl, aunque por ejemplo para probarlo usé:

elAst = {"tag":"Sequence","contents":[{"tag":"EntryPoint","contents":["al_empezar_a_ejecutar",{"tag":"None","contents":[]}]}]} 
edl = ""

Afortunadamente para nosotres no es blocking porque por alguna razón la segunda vez que corre es infinito más rápida.

¿Por qué la segunda vez es más rápido el análisis? ¿Les ha pasado a ustedes por ejemplo con el cli de scratch?

Abrazote grande y como siempre muchas gracias.

[flbulgarelli]

Ideas/comentarios:

1. Suena "razonable" por la forma en que haskell en general lidia con las computaciones, cacheando resultados previos; no me extrañaría que fuera algún tipo de implementación (menos eficiente) de thunks en JS. Hay que tener en cuenta que la versión JS es simplemente el mismo código pasado por un compilador GHC con un target diferente. No me extrañaría tampoco que fuera una cuestión de carga de algún runtime interno, pero me parece mucho más razonable la primera hipótesis. Dudo por tanto que se puede hacer algo al respecto.
2. Todo el soporte de Mulang basado en GHCJS es experimental y si bien todas las pruebas que hemos hecho han sido positivas siempre, no tiene el nivel de prueba en campo de batalla que sí tiene la versión nativa

Comentario general: parece que el proyecto GHCJS está muerto o muriendo, y stack ha sacado soporte para esta herramienta en sus últimas versiones. Esto es malo porque nos está empezando a complicar el propio desarrollo de Mulang, al lockearnos a versiones innecesariamente viejas de stack y GHC. De hecho, ya al día de hoy nos está complicando nuestro proceso de deploy y no estamos actualizando las versiones nuevas para JS con tanta frecuencia como la de mulang nativo. Estamos empezando a preguntarnos cuánto mas mantendremos la situación.

Hay quienes proponen pasar a otros compiladores inspirados en Haskell para JavaScript, pero eso hoy para nuestro equipo es prohibitivo, porque implicaría una reescritura y un mantenimiento por duplicado de la base de código. Me pregunto si entre nuestras dos organizaciones podríamos trabajar para mantener vivo a GHCJS.

[asanzo]

Extra extra: En Chrome anda MUCHO, MUCHÍSIMO más rápido. Fracciones de segundo. Apenas un "bump" en el gráfico. (Eso era en FF)

Sobre el mantenimiento, deberíamos charlar más a fondo. Por ejemplo ¿Qué significa mantener el GHCJS? En este momento dudo tener en el equipo gente que sepa lo suficiente de Haskell o de JS para esa empresa (me incluyo).