lumen

ng `(require 'torch)` and `(require 'nn)`, then dive into the Torch guides. You can bring Lumen's full macro system to bear on any ML problem, which greatly simplifies the boilerplate generation involved with standardizing datasets and such.

ake && bin/lumen`, you'll see the function is now defined when Lumen starts: > read-file function > (read-file "README.md") "Lumen\n=\nLumen is a very small, self-hosted Lisp for Lua and JavaScript. It provides a flexible compilation environment with an extensible reader, macros, and extensible special forms, but otherwise attempts..." Now we define `read-from-file`, which reads Lumen source code and returns it as a form that can be evaluated: (define-global read-from-file (path) (let (s ((get reader 'stream) (read-file path)) body ((get reader 'read-all) s)) `(do ,@body))) > (read-from-file "reader.l") ("do" ("define" "delimiters" ("set-of" "\"(\"" "\")\"" "\";\"" "\"\\r\"" "\"\\n\"")) ... Those are the forms defined in reader.l: https://github.com/sctb/lumen/blob/aedf2fd2c209bfc7926e0d4ea... Let's step through the forms and print them. > (step x (read-from-file "reader.l") (print (str x))) "do" ("define" "delimiters" ("set-of" "\"(\"" "\")\"" "\";\"" "\"\\r\"" "\"\\n\"")) ("define" "whitespace" ("set-of" "\" \"" "\"\\t\"" "\"\\r\"" "\"\\n\"")) ("define" "stream" ("str" "more") ("obj" more: "more" pos: 0 len: ("#" "str") string: "str")) ("define" "peek-char" ("s") ("let" ((pos: true len: true string: true) "s") ("when" ("<" "pos" "len") ("char" "string" "pos")))) ("define" "read-char" ("s") ("let" "c" ("peek-char" "s") ("if" "c" ("do" ("inc" ("get" "s" ("quote" "pos"))) "c")))) ... Pretty good! We're already doing some basic compiler-type stuff. That's Lumen's power: It's a flexible compiler. (IMO one of the finest in the world due to its simplicity.) Now, what can we do with these forms? Well, we can expand them: > (step x (expand (read-from-file "reader.l")) (print (str x))) "do" ("%local" "delimiters" ("%object" "\"(\"" true "\")\"" true "\";\"" true "\"\\n\"" true "\"\\r\"" true)) ("%local" "whitespace" ("%object" "\"\\r\"" true "\" \"" true "\"\\n\"" true "\"\\t\"" true)) ("%local-function" "stream" ("str" "more") ("return" ("%object" "\"more\"" "more" "\"pos\"" 0 "\"len\"" ("#" "str") "\"string\"" "str"))) ("%local-function" "peek-char" ("s") ("do" ("%local" "____id" "s") ("%local" "__pos" ("get" "____id" "\"pos\"")) ... We can compile them: > (print (compile (expand (read-from-file "reader.l")))) local delimiters = {["("] = true, [")"] = true, [";"] = true, ["\n"] = true, ["\r"] = true} local whitespace = {["\r"] = true, [" "] = true, ["\n"] = true, ["\t"] = true} local function stream(str, more) return {more = more, pos = 0, len = _35(str), string = str} end local function peek_char(s) local ____id9 = s local __pos6 = ____id9.pos local __len3 = ____id9.len local __string3 = ____id9.string if __pos6 < __len3 then return char(__string3, __pos6) end end local function read_char(s) local __c21 = peek_char(s) if __c21 then s.pos = s.pos + 1 return __c21 end end ... And we can switch languages: > (set target 'js) "js" > (print (compile (expand (read-from-file "reader.l")))) var delimiters = {"(": true, ")": true, ";": true, "\n": true, "\r": true}; var whitespace = {"\r": true, " ": true, "\n": true, "\t": true}; var stream = function (str, more) { return {more: more, pos: 0, len: _35(str), string: str}; }; var peek_char = function (s) { var ____id12 = s; var __pos8 = ____id12.pos; var __len4 = ____id12.len; var __string4 = ____id12.string; if (__pos8 < __len4) { return char(__string4, __pos8); } }; var read_char = function (s) { var __c28 = peek_char(s); if (__c28) { s.pos = s.pos + 1; return __c28; } }; ... Ok, on to the cool stuff. Make a file called lumen.l: (when-compiling `(do ,(read-from-file "runtime.l") ,(read-from-file "macros.l") ,(read-from-file "main.l"))) English translation: "When compiling, read the forms from runtime.l, macros.l, and main.l, join them together, then compile the result." Let's compile this file and see what happens: $ bin/lumen -c lumen.l environment = {{}} target = "lua" function nil63(x) return x == nil end function is63(x) return not nil63(x) end function no(x) return nil63(x) or x == false end function yes(x) return not no(x) end function either(x, y) if is63(x) then return x else return y end end ... Presto! We get bin/lumen.lua: https://github.com/sctb/lumen/blob/aedf2fd2c209bfc7926e0d4ea... Why does it generate Lua? Because on my system, Lumen happens to default to running on LuaJIT, and the host language is the default. If Lua wasn't installed on your system, you'd be seeing JS instead. To get a specific language, pass the `-t` parameter: $ bin/lumen -c lumen.l -t js environment = [{}]; target = "js"; nil63 = function (x) { return x === undefined || x === null; }; is63 = function (x) { return ! nil63(x); }; no = function (x) { return nil63(x) || x === false; }; yes = function (x) { return ! no(x); }; either = function (x, y) { if (is63(x)) { return x; } else { return y; } }; ... That gives us bin/lumen.js: https://github.com/sctb/lumen/blob/aedf2fd2c209bfc7926e0d4ea... Let's simplify the makefile. Open makefile in your edior and replace it with this: .PHONY: all clean test LUMEN_LUA ?= lua LUMEN_NODE ?= node LUMEN_HOST ?= $(LUMEN_LUA) LUMEN := LUMEN_HOST="$(LUMEN_HOST)" bin/lumen MODS := bin/lumen.x \ bin/reader.x \ bin/compiler.x \ bin/system.x all: $(MODS:.x=.js) $(MODS:.x=.lua) clean: @git checkout bin/*.js @git checkout bin/*.lua @rm -f obj/* bin/%.js : %.l @echo $@ @$(LUMEN) -c $< -o $@ -t js bin/%.lua : %.l @echo $@ @$(LUMEN) -c $< -o $@ -t lua test: all @echo js: @LUMEN_HOST=$(LUMEN_NODE) ./test.l @echo lua: @LUMEN_HOST=$(LUMEN_LUA) ./test.l Try it out: $ make -B test bin/lumen.js bin/reader.js bin/compiler.js bin/system.js bin/lumen.lua bin/reader.lua bin/compiler.lua bin/system.lua js: 647 passed, 0 failed lua: 647 passed, 0 failed Perfect. Our new lumen.l file fits into the compiler pipeline nicely. It may not seem like it, but we now have a tool of remarkable power. Let's see why. Open lumen.l back up. We recall it looks like this: (when-compiling `(do ,(read-from-file "runtime.l") ,(read-from-file "macros.l") ,(read-from-file "main.l"))) Let me show you what makes Lumen special. Change lumen.l to this: (define-global %lumen () (when-compiling `'(do ,(read-from-file "runtime.l") ,(read-from-file "macros.l") ,(read-from-file "main.l")))) (when-compiling `(do ,(read-from-file "runtime.l") ,(read-from-file "macros.l") ,(read-from-file "main.l"))) then compile: $ make Now change lumen.l to this: (define-global %lumen () (when-compiling `'(do ,(read-from-file "runtime.l") ,(read-from-file "macros.l") ,(read-from-file "main.l")))) (when-compiling (%lumen)) and compile again: $ make Here comes the surprise. Change lumen.l to this: (define-global %lumen () (when-compiling `',(%lumen))) (when-compiling (%lumen)) and compile: $ make Now delete the source code: $ rm runtime.l and compile: $ make -B test make -B test bin/lumen.js bin/reader.js bin/compiler.js bin/system.js bin/lumen.lua bin/reader.lua bin/compiler.lua bin/system.lua js: 647 passed, 0 failed lua: 647 passed, 0 failed What happened to the source code? It's gone! https://youtu.be/TGwZVGKG30s?t=25 Gone? What do you mean gone? I had perfectly fine source code and you mean to tell me it's gone?! Not anymore you don't. Poof. Yet lumen remains: $ make test js: 647 passed, 0 failed lua: 647 passed, 0 failed Last week I was trying to learn R, so I added a target for it: https://github.com/sctb/lumen/pull/193 Now I don't have to write R. Here's a (now very-outdated) branch that has full support for Python: https://github.com/shawwn/lumen/tree/features/python Now I don't have to write Python. This has been a short tour of why Lumen has fascinated me for the last three years, and hope you find its mysteries delightful. It is only through abstraction that we can bend computers to our will, and Lumen is a decisive step forward. Happy to answer any questions!

and document what they do, and show examples, and add test cases, then you never have to worry -- just like normal software. One helpful rule of thumb: If you copy some functionality more than twice, it's probably time to make it a function. If you define a set of functions repeatedly -- like test cases -- or find yourself writing the same pattern over and over, or if you can generate most of your structure automatically based on e.g. "I know this is a React component", it might be time to write a macro. If this concept sounds intriguing to anyone, I highly encourage you to check out Lumen: https://github.com/sctb/lumen It's a Lisp that's literally javascript: Compiled code: https://github.com/sctb/lumen/blob/master/bin/reader.js Original code: https://github.com/sctb/lumen/blob/master/reader.l So if you understand Javascript, then there's not much to learn. And you can use it in your own projects right away. Most of Lumen's brevity is thanks to macros. (One hack for quickly understanding Lumen: read the tests. Every language feature is meticulously demo'd: https://github.com/sctb/lumen/blob/master/test.l)

et mut lua_path = ""; let mut node_path = ""; for (name, value) in env::vars() { if name == "LUMEN_HOST" { lumen_host = &value; } else if name == "LUA_PATH" { lua_path = &value; } else if name == "NODE_PATH" { node_path = &value; } } println!("{} {} {} {}", bin, lumen_host, lua_path, node_path); Good luck with that! I'm sure there's a way to coax Rust into please-allow-me-to-just-compile-this, but the borrow checker is a cruel taskmaster. Whatever the syntax is, that's not it, and spending literally an hour trying to figure out how to store an environment variable into a separate variable doesn't feel very productive. That said, Cargo is amazing. It's truly a wonderful, delightful piece of software. Cargo crates plus a dynamic language seems like a recipe for success.