HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
sctb
lumen
JavaScript2015–2024
sctb / lumen

lumen

A Lisp for Lua and JavaScript

14Distinct people
54Mentions
1Explicit recommenders
571GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Lisp for Lua and JavaScript

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Lots of Lisp interest today! Here are a few resources. On Lisp: https://www.lurklurk.org/onlisp/onlisp.pdf Lumen - a Lisp for JavaScript and Lua: https://github.com/sctb/lumen…

shawn used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year54 dated mentions

Observed mentions: 2015-10-16 03:04:02 UTC to 2024-03-25 08:25:16 UTC.

0510152015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 17 mentions; 2 submissions, 15 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC606
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC615
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC17215
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC211
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC1019
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC624
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC211

What Hacker News says

6 sources
Cool! I'm trying to do something similar. I really think the time is ripe for a lisp-based game engine. I'll have more time to look into your work later, but I wanted to say (a) very cool! Keep it up! (b) check out Lumen (https://github.com/sctb/lumen). It compiles into Lua, and can be powered by LuaJIT. The benchmark performance is off the charts, on par with LuaJIT itself, because it compiles to code that mimics the way you'd write in Lua without any of the hassle. My current plan is to add support for running Lumen via luvit, which provides many libraries for LuaJIT, some of them useful for gamedev. If you're interested in some kind of a collaboration, shoot me an email or something. But regardless, best wishes and good luck! By the way, thanks for making this available under a permissive license. It's not always an easy decision, but
Read the rest
the gamedev industry in particular will be improved by choices like this.
In Show HN: Cleven – a Common Lisp experimental volume graphics game engine
ObjC's dot syntax? Sure. That's easy in Lumen: https://github.com/sctb/lumen/commit/6410c8cc2de66d1976515bd... Is it possible to use this technique to introduce, say, infix arithmetic operators? Yep! I wrote a macro to swap any instance of `x with the previous expression. Meaning, it allows you to write: (foo `= (x `+ y)) rather than (= foo (+ x y)) The reason it was so easy to do this is because `foo is shorthand for (quasiquote foo). So the macro simply steps through a body of code, looks for any instance of quasiquote followed by an atom, and then swaps it with the previous expression. But more generally, it's easy to write a macro to do whatever you want. If you really want infix expressions all of the time, I could imagine writing a macro which matches the pattern (... + ... + ...) and replaces it with (+ ... ... ...) Tha
Read the rest
t's made-up notation, but the idea is just "look for some set of symbols, like + or /, which occur within a list in between all of the other elements, and then move the symbol to the front of the list." The power is available to you, but whether you choose to use it is a separate question. Prefix notation tends to be a win for everything except math. And even for math, it's usually a matter of code formatting. Rather than (- (* 2 (/ (+ x y) (+ a b c))) 1) try (- (* 2 (/ (+ x y) (+ a b c))) 1) or (let u (+ x y) (/= u (+ a b c)) (*= u 2) (-- u)) Once Laarc has support for indentation-as-parens, it'd look like: let u (+ x y) /= u (+ a b c) *= u 2 -- u which is rather pretty, and has no ambiguity. One of pg's essays on Arc mentioned this feature, and it seems like a good idea, so I hope to pursue it.
In Show HN: `diff arc0 arc3.1`
A brief laundry list: - Arc embraces macros. - You can redefine anything. (assign + -) (+ 3 4) evaluates to -1. Not only are you an equal partner to the language, but the language is short enough to carry in your head. - Green threads. Here's a snippet from Laarc which does hot code reloading: (thread (on-err autoerr (fn () (while autoload* (sleep 0.25) (autoreload))))) It says "When an error happens, call the 'autoerr' function. Every 0.25 sec, check whether any source has changed, and reload it if so." But green threads make it so easy to do that in parallel. I never once had to worry about synchronization issues in the case of the autoreloader. - There's no FFI for Arc. However, I'm in the process of porting Arc from Racket to Lumen, which has a very in
Read the rest
teresting FFI thanks to LuaJIT: https://github.com/sctb/motor/blob/master/motor.l It's literally "copy-paste these C declarations. Now you can call those C functions." It quite simply rocks. If you're interested in Arc, consider Lumen as well. https://github.com/sctb/lumen It has many similarities to Arc, like a powerful macro system, and has some interesting distinctions, like keyword arguments and the FFI facilities.
In Show HN: `diff arc0 arc3.1`
By the way, Lumen is awesome. They've been working on it for about three years, and it shows. You should totally check it out: https://github.com/sctb/lumen Imagine a language whose startup time was faster than python / ruby / node, yet could be bent into whatever shape you wanted, thanks to macros. If you install luajit and run `make; make test`: $ time make test js: 525 passed, 0 failed lua: 525 passed, 0 failed real 0m0.153s user 0m0.119s sys 0m0.033s Lumen is wicked fast. Here's something cool: Our server is going to be running Lumen via luajit, yet it will serve a copy of itself compiled as javascript, which can execute in the browser. Same language, same syntax -- it just runs "in" two different languages at once! You'd think that it would be incredibly hard to do that well. Maybe it is, but they make it
Read the rest
look easy.
In Show HN: `diff arc0 arc3.1`
> I think I need something more emacs-based Numen [1] is an Emacs REPL we wrote for Parenscript + Node.js a few years ago. The version that's up on Github works with a different Lisp called Lumen [2] that compiles to JS and Lua, which we created partly as a Parenscript successor (it's self-hosted) but mostly as an experiment in a table-oriented Lisp [3,4]. But the differences between that REPL and the Parenscript one are trivial, and I can put the PS REPL up if anyone's interested. We still have plenty of code in Parenscript—including a Chrome extension we wrote to support HN moderation—so I use it every day. 1. https://github.com/gruseom/numen 2. https://github.com/sctb/lumen 3. https://news.ycombinator.com/item?id=3291065 4. https://news.ycombinator.com/item?id=6544926
In Enjoying Parenscript (Mostly)
Mmhm! But not without confusing the hell out of everyone. But who cares? It's fun! I should start by clarifying that I'm not associated with Arc in any way. Everything that I show should be thought of as an eager derivative, at best. But for several months a colleague and I have been working on a derivative, which we've been calling laarc, which incorporates a few additions that make it a bit easier to write programs with. Here's a debugger similar to pdb.set_trace(), for example: http://i.imgur.com/WWKa4kw.png Except when it breaks, it shows a list of the values of all the local variables. It's really useful for stepping through macro expansions and understanding them, because there's no longer any mystery when something breaks. Laarc isn't anywhere near ready yet, so it's too early to know whether it'll be useful generally, but
Read the rest
the goal is to discover a way to make programming feel like a Tesla. So, what are the benefits? Well, here's an example of a real-world program. It's all pimply and has a few hacks in it, but on the other hand, you can get a gist of how it might look: https://github.com/laarc/monki/blob/master/main.l Note that this was made two days ago, and I've been working very fast. So it's pretty rough. The program (monki) is essentially "cp for git", and while it works, it's not quite finished. Monki is Yet Another alternative to git subtrees / submodules; think of it like "cp for git". `monki clone voltagex/foo foo` would create a clone of that repo into the subdir "foo". But that subdir can be within one of your existing repositories. Here's the scenario it's useful for: https://github.com/tlbtlbtlb/startuptools This requires an installation of tlbcore (https://github.com/tlbtlbtlb/tlbcore) symlinked to this directory. With monki, you'd just type `monki clone tlbtlbtlb/tlbcore tlbcore` from within a clone of startuptools, and then you'd commit the result. Monki takes care of pulling updates, so that whenever tlbcore changes, startuptools would also get the new stuff. But you can `monki clone` a specific commit instead, if you want to pin to a "known working" version. Anyway, that monki business was the result of trying to answer "What's a simple way where I can share code between all my repositories, pull in updates as I make them, and not have to worry too much?" And it was a good chance to exercise... Lumen! Confused yet? Ok, so Arc runs on Racket. So did Laarc. Then we had the good fortune to hear about Lumen: https://github.com/sctb/lumen It's a Lisp that compiles to either Javascript or Lua. It literally exhibits the same behavior whether you're running via luajit, node, or the browser. Since LuaJIT's FFI is awesome, that makes it incredibly easy to interface with existing C libraries using Lumen. Just look how beautiful his postgres bindings are! https://github.com/sctb/motor/blob/master/pq.l That should catch anyone's attention -- the FFI is literally "copy paste some C declarations and you're done." I want to take that further. In Lumen, it's already possible to interface with node libraries or with lua libraries as-needed. What if we extend it to work with python and go libs as easily as it works with C? You might end up with a language that could do any given task very easily, because you'd simply use whatever library happens to be convenient regardless of whether it's a C lib, a node package, or a Ruby gem. So why have I been yakking about Lumen? Because it seems like it offers a bunch of interesting benefits as a runtime. I've been porting Laarc from Racket to it, slowly. It's extremely early, but here's an early version of the compiler: https://github.com/laarc/lumen-arc/blob/master/arc.l ... It's essentially ac.scm. I wanted to make it match as closely as possible, both because ac.scm is a good answer to "What's a good way to write a lisp compiler in a lisp language?" and because it's dangerous to assume you can write from scratch something that a smart team has been thinking about and working on for 13 years. Sooo... That's a whirlwind tour of stuff that's not even ready to tour. On the plus side, the plan is to get an in-browser repl running soon (arc can already run in the browser, so it's a matter of coaxing CodeMirror into submission). There's a server running Lumen over at http://arc.lol:9999 which does absolutely nothing useful yet. The plan is to get a REPL up and to dub it "Arc dot tiefighter" since "lol" obviously looks like a tie fighter.
In Show HN: `diff arc0 arc3.1`

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.