What does HackerNews think of stalin?

Carp – a statically typed, non-GC Lisp language | Dec 2022

Somewhat related; Not statically typed nor maintained, but nice work nonetheless [0].

Compiling Dynamic Languages (2013) [pdf] | Apr 2019

> Classically, dynamic languages have been interpreted, that is, evaluated at run- time by an interpreter program. In recent years, dynamic languages have also been complied, that is, translated to another language such as native code before being executed.

Strange, I thought I have seen compilers for languages like BASIC for a long time. The first LISP compiler is from the early 60s: http://www.bitsavers.org/pdf/mit/ai/aim/AIM-039.pdf

Scheme compilers are from the 70s. Rabbit for Scheme: https://dspace.mit.edu/handle/1721.1/6913

> We conclude that ahead-of-time compilation is a viable alternative to interpretation of dynamic languages

Especially when the AOT compiler can be used incremental and the program can be extended/modified incrementally. See sbcl.

> The project then showed that it is possible to compile this dynamic language ahead-of-time to a native binary, using a statically typed language as an inter- mediate step.

This has been known for a long time.

For example Kyoto Common Lisp from 1985: http://www.softwarepreservation.org/projects/LISP/kcl/doc/kc...

Design and Implementation of KCL:

http://www.softwarepreservation.org/projects/LISP/kcl/paper/...

KCL has been morphed into newer implementations like ECL and CLASP (addresses LLVM) over the years.

Or CLICC:

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=522...

Or Stalin for an attempt on a highly optimizing whole-program compiler for Scheme: https://github.com/barak/stalin

> Overall the project found that compiling a dynamic language ahead-of-time is a viable alternative to interpreting the language

See SBCL: http://www.sbcl.org

Stali: A new static Linux distribution | Sep 2016

Expand Context ↕

The name is taken.

https://github.com/barak/stalin

Implement a programming language from scratch | Mar 2015

Expand Context ↕

Too late, someone already did that and measured the overhead of up to five interpretations layers: "Scheme benchmarking with a meta-circular" interpreter http://yinwang0.wordpress.com/2013/11/04/scheme-benchmarking... Archive: http://web.archive.org/web/20140105145428/https://yinwang0.w... HN discussion: https://news.ycombinator.com/item?id=7045734 (25 points, 443 days ago, 9 comments) (The main critic is that it should compare more scheme implementations.)

Many modern schemes (and similar languages like Racket and Clojure) have many optimization, use bytecode and jit compiling, so the abstraction overhead is not as big as in the naive versions. And you get nice code and powerful macros in exchange.

IIRC Stalin is faster than C in some benchmarks, but the compiling time is very big. "Stalin: a global optimizing compiler for Scheme" https://github.com/barak/stalin HN discussion: https://news.ycombinator.com/item?id=8214343 (85 points, 220 days ago, 70 comments)

On eval in dynamic languages generally and in Racket specifically (2011) | Jul 2014

eval is not a good idea if you want to write a compiler that generates small efficient binaries either. This is why, for example the Stalin Scheme compiler does not include eval.

"Running that image has equivalent semantics to loading the Scheme source file into a virgin Scheme interpreter and then terminating its execution. The chief limitation is that it is not possible to LOAD or EVAL new expressions or procedure definitions into a running program after compilation. In return for this limitation, Stalin does substantial global compile-time analysis of the source program under this closed-world assumption and produces executable images that are small, stand-alone, and fast."

https://github.com/barak/stalin

GCC 4.9 Release Series – Changes, New Features, and Fixes | Apr 2014

Expand Context ↕

For an example of a compiler other than GCC that does whole-program optimization see the Stalin Scheme compiler: https://github.com/barak/stalin