[throw009]

>Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity:

You're 90% there. Lisp notation obviates the need for arity tracking, which is why in lisp + and sum are the same function:

    scheme@(guile-user)> (+)
    $416 = 0
    scheme@(guile-user)> (+ 1)
    $417 = 1
    scheme@(guile-user)> (+ 1 2)
    $418 = 3
    scheme@(guile-user)> (+ 1 2 3)
    $419 = 6

Add higher order functions, e.g. (λ (x) (x x)), and lisp notation is the simplest/only way to deal with the general case where you don't know ahead of time the arity of the function you'd be applying because of partial currying and data persistence.

As for the parsers this was 10 years ago at university. I've long since lost the source code. There weren't any problems with python, it's just that once I wrote the lisp version I realized just how useful the brackets actually are. There's a reason why every computer language is more or less context free. Lisp just takes that to its logical conclusion.

[danuker]

Well, thank you for your feedback. I don't know why I bothered with the flat list in the first place. I might rewrite this library in Clojure. And I might blog about my findings.

Cheers!

[throw009]

Some advice: move to emacs regardless of what editor you use. Evil mode is the best vi clone there is. Use paredit for any lisp like language, you are editing the sexpression tree directly, not it's incidental textual representation. Use the mode for the dialect of your choice. You will never need to exit emacs and will be able to experience the repl as it was it was meant to be.

[noloblo]

Thanks between clojure sbcl racket and scheme which is the fastest language of am lisps?

[Atlas22]

If you are referring to fastest in terms of wall & CPU time running. Without spending a lot of time optimizing your code yourself, I suspect SBCL would take the crown for vast majority of cases. If you do hyper optimize, the gap with scheme largely closes (sometime scheme wins, sometimes SBCL). So I'd go with SBCL if all else is the same feature wise to you. That said, the last serious benchmark I did of lisps was ~2010 so optimization may have changed since then and of course they were not very rigorus benchmarks (just my compute-bound workload at the time, that primarily boiled down to mostly integer ops). Debian language benchmarks game has some benchmarks written for sbcl and racket that may be good for comparing implementations yourself if interested. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[butt___hugger]

SBCL, probably. Scheme would be a close second depending on the implementation (Chicken, Gerbil or other compile-to-C impls.) Racket and Clojure are closer in performance to scripting languages like Python.

[danuker]

In the TechEmpower benchmarks, Clojure is about 2.75x slower than Java, while Python is 5.59x slower.

The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%.

https://www.techempower.com/benchmarks/#section=data-r21&l=z...

About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation):

https://www.techempower.com/benchmarks/#section=data-r21&l=z...

I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to you?

https://github.com/TechEmpower/FrameworkBenchmarks/blob/73eb...

[lycopodiopsida]

There is a fun blog series about comparison and tweaks of the same problem between java, rust and CL. I will link only the last part of the series[1], but the general take is that SBCL performs comparably to a heavily optimized java implementation, and can even hold a candle to rust and java on short runs.

[1] https://renato.athaydes.com/posts/revenge_of_lisp-part-2.htm...