Femtolisp: A lightweight, robust, scheme-like Lisp implementation
github.com
github.com
(Not to detract from Julia devs but there were plenty of Lisp based contenders ready for scientific computing before so its useful to ask why Julia why now etc )
*edit: this was kinda snarky but I actually meant a compliment on the excellent strategic choices Julia devs made as compared to other scientific computing attempts
And when people discover the lispiness in Julia which is a thin layer below the surface syntax (such as the metaprogramming system and multiple dispatch) they at least already gave the language a fairer chance. Other languages that borrowed from Lisp but didn't go, to different degrees, with s-expr like Scala and Clojure (plus R) also had success in the data science/ML area. Hopefully Nim also gets a foothold, and possibly Racket with optional infix syntax.
As someone who is a Julia fan, but has a background from mathematics rather than computer science, I don't agree. Julia syntax resembles mathematics only on a very superficial typographic level that have little actual significance when reading or writing code.
Mathematical notation, unlike code, is fundamentally two-dimensional, with vertically written fractions, subscripts and superscripts, etc. Simple mathematical expressions are easy to read in both Julia and S-expression notation. More complicated expressions are hard to read in Julia (I sometimes have to write them out by hand on paper in order to understand them), while the same expressions written in properly indented S-expression syntax with a generous use of newlines are easy to read. They are somehow structurally more similar to standard 2-dimensional mathematical notation, despite the superficial infix vs prefix differences.
What attracted me in the first place to Common Lisp (my first programming language) as a person with no technical skills or experience was the friendly and intuitive syntax. It was the first programming language I saw that didn't look visually intimidating. These days I use Julia, but I use it for the awesome features, libraries and community, not for the syntax. I would love Julia even more if it used S-expressions.
And as Julia gets more mature and popular, I wouldn't be surprised if more people notice the strength of it's ecosystem and start creating new language that targets it, just like Elixir and Erlang or all JVM machines (and something more than just reader macros like LispSyntax.jl, like having full editor support and exclusive features that makes it unique compared to Julia). A JuliaLisp could have an amazing interop with the main language, and serve as an alternative for those who prefer s-expr.
It's one thing that Julia currently does "ok" with, the syntax is fine (albeit slightly more verbose and often more abstract), but the iteration speed gets fairly nasty when you're not doing big computations or need to rapidly iterate, in which the JIT can take awhile to warm up. There are things you can do, but it's still a lot slower for day to day work for a lot of MATLAB users.
At least in my opinion. I tried to switch to Julia from GNU Octave (from which I moved from MATLAB proper) for a lot of hobby controls/DSP work and it was just a pain to iterate and explore ideas with. Same with Python imo as well.
```
julia
julia> include("file.jl") # when you want to reload, ctrl-c then arrow-up and enter to include again
```
This isn't so dissimilar to MATLAB in some respects: you don't restart MATLAB every time you want to re-run your code.
julia> includet("file.jl") # Notice the final 't' in 'includet'
This will cause file.jl to get automatically reloaded whenever it is changed.
This is a very hard truth for the more aspbergery wing of lisp users to accept.
Generally, s-expressions is not a particular popular or needed tool. We've seen similar systems for code data&representations though - for example XML was used to represent code, too.
Plenty of inside info on these comment threads.
Yes, and this is practically the only thing that I find wrong with Julia, besides the lack of the interactivity of CL.
It's like populism -- an inferior syntax choice taken just to attract the Pythonistas.
And secondly, Lisp programmers are also human, and more power means more responsibility. When you have a language to create any language, people are tempted to do it, but a language is also a social construct, not just technical (a language only has value if many people talk it, which means documentation, community, support...), and making it so easy to make your own that you end up ignoring that aspect is the Lisp Curse. Modern languages actually see value in limiting the power, by either removing it completely (like Go), or hiding it/making deviations explicit (like Julia's surface syntax and macro identifier '@' which alerts the user that he is deviating from the "first class" language that everyone is supposed to know).
I like being able to do this:
(+ 1 2 3 4 5) 1 + 2 + 3 + 4 + 5
+(1, 2, 3, 4, 5)
>Lisp Mode
I wish every language had Lisp Mode, haha
Of course, LispSyntax.jl still has some glaring omissions that someone should really get around to implementing.
* this is intentionally under-specified, but to me it means some nontrivial subset of matlab/numpy functionality
In all seriousness that's probably the quickest way, if by 'lisp' you mean 's-expressions'.
For a real lisp, maybe these Numpy bindings[0] for Chez Scheme? Although the py-* names look a bit awkward. You could easily rebind those, but maybe that's not "out of the box" enough.
“Downloadable Windows LA REPL” was a criteria Julia met within ~6-8 months of public release, and it was one of the reasons I got involved even though I only ever use(d) windows at work (...mostly for scientific instrumentation which shipped with and only supported windows).
This is slowly changing, but IMO windows support is still table stakes for a scientific computing environment, and seeing windows support meant both that I could use it where I most needed it, and signaled that Julia had potential for real traction (not abandoning >70% of users out of the gate). I think windows support is also one of the reasons Python/NumPy got to be where it is — it wasn’t always perfect, but they at least cared about windows, more so than most other scripting languages in the mid-2000s. Ditto CMake.
Any examples?
numcl, a numpy clone in Common Lisp - https://github.com/numcl/numcl
Clojure kixi-stats- https://cljdoc.org/d/kixi/stats/0.5.0/doc/readme
and the book Clojure for Data Science - http://clojuredatascience.com/
Clojure's Incanter has been mentioned already - http://incanter.org/
OWL, the OCaml Scientific Computing project - https://ocaml.xyz/
And probably not quite what you're looking for, but there is a Racket data frame structure which provides some data science like manipulation capabilities - https://alex-hhh.github.io/2018/08/racket-data-frame.html
Appreciate some of the above are Schemes and not Lisps, but they may still be interesting.
Common Lisp has been used in scientific computing since decades, so in some sense it's "ready". Also, see CLASP: lisp at the state of the art of computational chemistry.
julia --lisp"""
Almost everybody has their own lisp implementation. Some programmers' dogs and cats probably have their own lisp implementations as well. This is great, but too often I see people omit some of the obscure but critical features that make lisp uniquely wonderful. These include read macros like #. and backreferences, gensyms, and properly escaped symbol names. If you're going to waste everybody's time with yet another lisp, at least do it right damnit.
"""
FYI the link to microscheme is broken, this works: https://ryansuchocki.github.io/microscheme/
Judging by the prominent "microscheme.org" at the top of that page, the link is supposed to work, but anyone's guess when it might be fixed...
https://github.com/JeffBezanson/femtolisp/blob/master/tiny/s...
Anyone know where I can read more about the VM and its human-readable syntax? I'm not immediately spotting it in the repo.
#fn("8000r1e0~|[316>0\x7fM~|[i2i343;];" [closure?])] find-in-f)
#fn(";000r2c0~|}q3c1tg66I0c2e3c4c5e6g63132c73241;c8;"
[#fn("8000r0c0c1~\x7fq2i2322^;" [#fn(for-each)
#fn("8000r1~M|\x7f_43;" [])])
#fn("6000r1|F16B02|Mc0<16802|\x84c1<680e2|41;c3|41;" [thrown-value
i couldn't really find any docs about it either, but compiler.scm is pretty readable and has an instruction listing – their arguments aren't documented explicitly, but you can infer most of it from the code for `compiler::disassemble`, which is quite readable too.
the instructions remind me of CPython, pretty standard stack-machine stuff: slots for locals (`loadv 0` where 0 is an index to func_values), loading globals by name (`loadg 0`, same as with values but the value is a symbol to be looked up), relative jumps, things like that.
for no reason in particular i spent an evening[0] reverse-engineering enough of the code to be able to parse/display bytecode strings :) here's the python code [1] if you want to try it, though it'd probably be easier to just install femtolisp and use its `disassemble`...
as others have mentioned, the serialized form is kind-of readable, and with some practice you could probably even read it directly! e.g "c0" is `loadv 0`, ";" is `ret`, functions always have a header like `r3` indicating 3 arguments, etc. reading it like that would be very tedious but doable in a pinch, and at the very least you can see patterns like the ones i mentioned
i've only looked at the bytecode and vm, but if you were more serious about using the language, the `compiler` module seems to have a nice API for creating bytecode. (they just directly expose all the functions the compiler uses!)
---
[0] would've gone much faster if i'd known they shift each byte by 48 when serializing...
[1] https://gist.github.com/lubieowoce/148406b1dd61d91b1584339ff...
It adds 48 to each byte being printed, which is ASCII '0'.