HVM VS SICL

Sorry I only just saw this - the URL was changed because you have this in the HTML:

Reminds me of HVM[0]

[0]https://github.com/HigherOrderCO/HVM

Really interesting to see how new lang concepts and refinements keep popping up this last decade, between Vale, Gleam, Hylo, Austral...

Linear types really opened up lots of ways to improve memory management and compilation improvements.

I have a tangential question that is related to this cool new feature.

Warning: the question I ask comes from a part of my brain that is currently melted due to heavy thinking.

Context: I write a fair amount of Clojure, and in Lisps the code itself is a tree. Just like this F# parallel graph type-checker. In Lisps, one would use Macros to perform compile-time computation to accomplish something like this, I think.

More context: Idris2 allows for first class type-driven development, where the types are passed around and used to formally specify program behavior, even down to the value of a particular definition.

Given that this F# feature enables parallel analysis, wouldn't it make sense to do all of our development in a Lisp-like Trie structure where the types are simply part of the program itself, like in Idris2?

Also related, is this similar to how HVM works with their "Interaction nets"?

https://github.com/HigherOrderCO/HVM

https://www.idris-lang.org/

https://clojure.org/

I'm afraid I don't even understand what the difference between code, data, and types are anymore... it used to make sense, but these new languages have dissolved those boundaries in my mind, and I am not sure how to build it back up again.

Impressive presentation but I find two things missing in particular:

* GRIN [1] - arguably a breakthrough in FP compilation; there are several implementation based on this

* HVM [2] - parallel optimal reduction. The results are very impressive.

[1] https://link.springer.com/chapter/10.1007/3-540-63237-9_19

[2] https://github.com/HigherOrderCO/HVM

Purity has nothing to do with memoization. Haskell's semantics never "rewrite under a lambda" (unlike, e.g. HVM). Calling (\_ -> e) () twice will (modulo optimizations) always perform the computation in e twice.

This is a very approachable paper from 1990 on one way to do it with a C kernel bootstrapping to Common Lisp: https://www.softwarepreservation.org/projects/LISP/kcl/paper... Kyoto Common Lisp (KCL) is the ancestor of today's Embeddable Common Lisp (ECL).

SICL is probably the best modern version of CL written in CL from a design standpoint, even if it's not taking over SBCL's role anytime soon: https://github.com/robert-strandh/SICL It uses some fancy bootstrapping to have the whole language available early, e.g. their definition of class 'symbol is:

    (defclass symbol (t)

That's pretty much the objective of SICL, which is "intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL, rather than having to maintain their own, perhaps implementation-specific versions".

   https://github.com/robert-strandh/SICL

Gladly!

https://github.com/robert-strandh/SICL (which I wrote a decent chunk of the compiler backend of.)

I applaud your curiosity and initiative to explore. Are you aware of https://github.com/robert-strandh/SICL?

I mean this Klein and this SICL. Self and Common Lisp are memory-safe, though the implementations need capabilities to manipulate memory; SICL encapsulates them using first-class global environments.

There is significant overlap with SICL and its associated pieces which supply many of the other parts needed to make a Common Lisp. Some of these are Cluster which provides a portable and extensible assembler, Eclector which supplies a portable and extensible reader, Concrete-Syntax-Tree that supports source code tracking during compilation, ctype that implements the Common Lisp type system, and Clostrum that provides first-class environments for e.g. run-time, evaluation, and compilation. The SICL project has as one of its goals the creation of portable infrastructure for implementing Common Lisp, and these pieces are novel building blocks that were created as part of the project.

Not really; you can do it with primitive operations e.g. here is the list in the Cleavir compiler and a paper on "magic" in Jikes RVM. SBCL also has a "virtual op"/vop language for code generation, and vops are written to manipulate objects with assembly snippets.

Both work. I basically never have to touch C or even FFI (cl+ssl being the main use of FFI for me), unless I am poking at SBCL guts in my spare time, and that isn't necessary either. I am sure many Haskell hackers are happy with their IO monad too.

It's used in operating systems, compilers and CLIs.

The Cleavir Common Lisp compiler uses three-address instructions in a control-flow graph, though it is intended more for production use than educational use.