
Fnl: zero-overhead Lisp syntax for Lua - zeveb
https://github.com/bakpakin/fnl
======
bakpakin
Original author here:

The largest reason for use of S exprs is making Meta programming easier. While
certain things like arithmetic are more difficult with S-exprs, Macros and
DSLs are far easier than with C like syntax. Since Lua is actually only a few
steps from something like Guile, it takes very little code to translate a
scheme like language to Lua without adding too much runtime overhead. The
difficult parts of lisp to implement, namely closures, come for free.

With LuaJIT as good as it is, I would not be surprised if something like this
would outperform guile.

~~~
bjoli
As a guile fanboy, I doubt outperforming guile is very hard (even though it is
fast enough for most uses).

LuaJIT is most certainly faster than guile, but it isn't a very good
comparison. Guile is far from the fastest lisp (or even scheme, for that
matter), whereas LuaJIT is probably the best JIT on the planet.

~~~
WalterGR
_LuaJIT is probably the best JIT on the planet._

Where can I learn more about how LuaJIT compares to other JITers?

~~~
wruza
LtU has an old, but interesting thread. Can’t tell how much details changed
from that time, but since 1Gb limit was removed from LJ recently, it is my The
Only Dynamic Language to Consider.

    
    
      http://lambda-the-ultimate.org/node/3851

~~~
bjoli
Mike Pall indulges in some (well deserved) gloating far down in the thread:

LuaJIT also does: constant folding, constant propagation, copy propagation,
algebraic simplifications, reassociation, common-subexpression elimination,
alias analysis, load-forwarding, store-forwarding, dead-store elimination,
store sinking, scalar replacement of aggregates, scalar-evolution analysis,
narrowing, specialization, loop inversion, dead-code elimination, reverse-
linear-scan register allocation with a blended cost-model, register hinting,
register renaming, memory operand fusion.

Due to the nature of a trace compiler, it implicitly performs partial and
interprocedural variants of all of them. And many traditional optimizations,
like straightening or unreachable code elimination are unnecessary.

All of that in 120KB for the VM and 80KB for the JIT compiler. And I didn't
need 15 years and a billion dollar budget for that, either.

I'm planning to add value-range propagation, array-bounds-check elimination,
escape analysis, allocation sinking, if conversion, hyperblock scheduling and
auto-vectorization. Anything I forgot? I'll see what I can do. :-)

------
peatmoss
I don’t have much cause to write Lua, but I can very much support lispy
syntax.

When we all started coding, we probably used a text editor and thought in
terms of editing characters: backspacing, typing, maybe mousing around for
bigger changes.

Then at some point we graduated to a programmers editor where we got
comfortable cutting, pulling, yanking, killing larger units of text: words,
lines, paragraphs.

With tools like paredit, you can take another evolutionary step to edit the
structures of your code. I find this very productive. It feels a little like
those code block programming languages for kids.

If for no other reason than to enable slurping and barfing code structures in
my text editor, this is a win. May all languages someday have a lisp syntax.

~~~
drb91
I'm with you almost all the way.... however, I think what we should learn here
is that every language deserves tools as powerful as paredit--that is, ast-
aware editing--not that all languages should convert their ast to
s-expressions.

Imagine not being able to save syntactically incorrect code, or being able to
have semantic diffs between domain objects (e.g. functions, classes, strings,
types, apis) rather than thinking in terms of characters and lines, or being
able to query a code base, like "find me all places where I assign to a
variable named 'status' with type under 'error' and list me the names of the
functions whose frame the variable belongs to". Paredit is simply where text
and ast manipulation converge to the closest point.

~~~
thesmallestcat
As a fallback. I like LISPs as much as the next guy/gal, but editing the AST
_by default_ is too low-level. The importance of paredit is a language smell
in my opinion, not something to aspire to.

~~~
jorams
Can you explain in which direction something better should go? The AST is very
much at a higher level than how the vast majority of programming is done,
which is by manipulating the text that later gets parsed into an AST. I'm
having trouble envisioning what editing a higher level than the AST would look
like, without jumping straight to visual programming, which I find very
inefficient in every incarnation I've seen. (And we could debate how far
_above_ an AST such systems actually are.)

~~~
briankelly
That seems backwards to me - AST-aware editing is basically embedding more of
the compiler into the editor. It seems more valuable to me to be writing in a
language that can express higher level concepts with lesser boilerplate, which
would eliminate the need (and make far more difficult) for AST aware editing.

~~~
cptn_brittish
In regards to lisp a large amount of lisp editors are written in lisp so they
do already do exactly that'

~~~
kazinator
You might be surprised how little a Lisp dialect brings to the table
specifically for developing the text editor features geared toward editing
specifically Lisp.

The data structure representing Lisp data (i.e. code) is stripped of relevant
text editing attributes, like how it is divided into lines and using what
indentation, and, oh those semicolon-delimited comments.

Text editors also have to let the user deal with bad syntax.

So it's not just a matter of, "oh, we're written in Lisp, so just hand the
buffer to the Lisp reader, do something and spit it out again".

------
zitterbewegung
This could be interesting to integrate support for racket to allow it to
interact with Torch. You would just create a small language to compile to lua
and then have that run in Torch.

[https://github.com/torch/torch7](https://github.com/torch/torch7)

[http://racket-lang.org](http://racket-lang.org)

~~~
scottlocklin
Back to Lush...

------
AHTERIX5000
This is really interesting! I've been looking for a Lua-like Lisp
implementation that would be as easy and clean to integrate, something that
would compile with clang/gcc/msvc easily and allow spinning up multiple
interpreter instances without having any global state. Only TinyScheme comes
quite close I think.

