
Valtan: Common Lisp to JavaScript Compiler - simonpure
https://github.com/cxxxr/valtan
======
threatofrain
Also potentially coming down the line is JACL (Javascript-Assisted Common
Lisp), a web-app focused dialect of Common Lisp.

[https://tailrecursion.com/~alan/documents/jacl-
els-2020-draf...](https://tailrecursion.com/~alan/documents/jacl-
els-2020-draft.pdf)

------
_wdoa
I'd hold off on getting too excited about this. Until it:

\- Is fully featured and has a conditions and restarts system that works on
JS, and has CLOS, multimethods, etc

\- Has great interop with the existing JS ecosystem. No painful conversions to
and from CL, works/is documented well with existing JS tooling like parcel,
webpack, mocha, etc

\- Is close to being fully featured and not just implementing <50% (usually
<30%) of the features of the language \- Is production ready -- no weird
compiler bugs, I can use this with real business

\- Has a powerful linting tool -- A linting tool that can blacklist/whitelist
a subset of common lisp macros and expressions that can be used in a project.
You would need something like this for a real company to prevent the team from
shooting themselves in the foot. Could probably be done in CL, sblint comes to
mind but it's not well documented (like most lisp libraries) so I'm not sure.

\- Culture changes: specifically the community needs to document things much
better and be more pro-social instead of living on an island. Backend workflow
needs good docs. Ex: I think fukamachi's web frameworks supersede weblocks
afaict? not sure, but he has like half a dozen or so web frameworks and it's
not obvious which one to choose. Ningle? utopian? caveman? clack + woo?
documentation in most CL libraries are really lacking and you need to dig into
the source

\- Run CL programs without opening a debugger. Modern day workflows have CI
pipelines and automation out the wazoo. CL expects you to run the debugger
manually. There's a way to run asdf projects like a script but it's not well-
documented

\- The debugger needs to be more user friendly. Don't get me wrong, the
debugger is one of the coolest features of CL, but asking a plain old JS dev
to try to understand those low level stack traces is a form of torture. It's
roots come from lower level programming, but newer devs want to use it for web
app dev (like this to-js compiler posted here). A nicer, easier to understand
layer like ReasonML's BetterErrors would be needed or an update to CL itself

\- A real package manager. Not quicklisp -- that's a curated package list
where you need to talk with a single person who approves it to get your
package published

------
_threads
I see a lot of Lisp stuff on HN : do a lot of people use it ?

~~~
gibsonf1
We use it for the core of our AGI and our in-memory graph db in full
production - very very fast. The web libraries for lisp are very good as well
with Fukamachi libraries, such as [1] caveman and [2] woo (fastest web
server), [3] dexador, [4] websockets, also [5] parallel processing, [6] rtg-
math incredibly fast math library including quaternion support, etc.

[1]
[https://github.com/fukamachi/caveman](https://github.com/fukamachi/caveman)
[2] [https://github.com/fukamachi/woo](https://github.com/fukamachi/woo) [3]
[https://github.com/fukamachi/dexador](https://github.com/fukamachi/dexador)
[4] [https://github.com/fukamachi/websocket-
driver](https://github.com/fukamachi/websocket-driver) [5]
[https://github.com/lmj/lparallel](https://github.com/lmj/lparallel) [6]
[https://github.com/cbaggers/rtg-math](https://github.com/cbaggers/rtg-math)

~~~
dreamcompiler
Last time I checked, woo doesn't support TLS. Has that changed?

~~~
p_l
Given present day approach of using reverse proxies for TLS termination,
that's not much of a limitation.

~~~
dreamcompiler
That's the solution I use with mod_lisp running behind Apache too, but I'd
like to get away from Apache. I'll try haproxy.

~~~
p_l
HAproxy is really, really good.

Personally I also use nginx as reverse proxy a lot, but that's more because
there's a ready to use _Ingress Controller_ for kubernetes that uses it
internally.

------
zelly
Now do WebAssembly.

~~~
diggan
Not CL but still lisp > WASM: [https://github.com/roman01la/clj-
wasm](https://github.com/roman01la/clj-wasm)

Previous discussion:
[https://news.ycombinator.com/item?id=21604850](https://news.ycombinator.com/item?id=21604850)

~~~
fulafel
No, that's just a Clojure inspired syntax for WebAssembly.

~~~
diggan
Yeah, that's true. Sorry, misunderstood the scope of the project.

But I guess it's closer to Common Lisp than what WASM's text format is, so
might be helpful for some.

------
hashkb
There are too many incomplete lisp-on-js solutions. No, CLJS doesn't count. It
would be so awesome if one ever made it to actual usable maturity.

Is it too hard? Is there something that makes everyone give up? Or is lisp
just too academic for most people to care?

~~~
rini17
It could be done using WebAssembly. But AFAIK all existing Common Lisp
implementations want to manipulate the stack in ways that WASM disallows.

~~~
register
Can you be more specific about the peculiar way in which CL manipulates the
stack? Where to find more details about CL internals?

~~~
rwallace
In CL, if you catch an exception, you have the option of trying to fix the
problem and then letting the code continue from where it left off. This is
only moderately difficult to implement in machine code, but somewhere between
problematic and impossible on a high level platform that has already
implemented exceptions by stack unwinding.

