
Rhine – A Lisp on LLVM - artagnon
https://github.com/artagnon/rhine
======
pjmlp
Nice, but the author could join efforts with one of the few attempts to have a
native Clojure compiler instead.

Another remark, is that it would have been nicer to have the language being
made in itself instead of OCaml.

Other than that, very nice work.

~~~
artagnon
Actually, there's a hidden motive behind not targeting Clojure: the eventual
plan is to allow Elisp-like mutability so it can be used to build an Emacs-
like editor.

I chose OCaml because of the relatively mature OCaml-LLVM bindings. A self-
hosting compiler is a lot of work: it'll require Rhine-LLVM bindings first.

~~~
DennisP
So you're building an Emacs-like editor on an Elisp-like language. What are
you hoping to do differently than Emacs?

(Not being snarky, languages and text editors are both interesting projects
and worth experimenting with, and combining the two is especially interesting
to me.)

~~~
ANTSANTS
A new editor that copied emacs' good Lisp support and insane customizability
via hooks for _everything_ but had an interface that was approachable for
regular desktop users (tabs instead of buffers, good CUA-style keybinds out of
the box, no surprising weirdness like nonlinear undo, etc) is about the single
most important thing anyone could do to increase the popularity of the Lisp
family. Right now, if you want to write Lisp, your choices are:

emacs, which is utterly unapproachable for newcomers, and will always be
uncomfortable to use for people that grew up with "modern" desktop GUIs,
because it and most of its userbase predate established interface standards
and they like it that way.

DrRacket, which is a step in the right direction but is Racket-specific,
bloated, slow, and somewhat buggy.

LispWorks, which is proprietary and prohibitively expensive unless you _sign
up_ for and are allowed to use the crippleware version.

Given those choices, it's not surprising that most people just give up on Lisp
and use languages that you could comfortably program in Notepad if you had to.

------
sarnowski
Someone mentioned the JVM interop of Clojure is it's main selling point. While
its definitly awesome to have that great integration (I'm a heavy interop
user), for me, the main strength is having persistent data structures at its
base for everything. I myself played with the thoughts of creating a native
runtime based on Clojure's syntax and data structures. I cant see that this
project uses persistent data structures. Am I wrong? please enlighten me.

~~~
Slackwise
> for me, the main strength is having persistent data structures at its base
> for everything.

Agreed, but also:

\- The ISeq abstraction

\- Software Transactional Memory for state management

\- Structure-sharing of the persistent structures, for added
efficiency/performance

And of course, all the nice reader macros that make things so much easier to
read.

This project is cool, but what I'd rather see is Clojure becoming parasitic,
living on all the host VMs it can. We've got the CLR version, and
ClojureScript for V8/JS, but we could also have it properly on top of Python,
Ruby[1], Lua, Erlang, and LLVM.

[1]: I know Rouge exists, but I'm not sure how well it's progressing.

~~~
bjeanes
> Structure-sharing of the persistent structures, for added
> efficiency/performance

I think the structural sharing is the definition of persistent data
structures, as distinct from immutable data structures in general.

~~~
Slackwise
> I think the structural sharing is the definition of persistent data
> structures, as distinct from immutable data structures in general.

Oh, yes, you are very much correct. I just wanted to highlight that is itself
a feature of Clojure's behavior.

------
splix
also [https://github.com/eudoxia0/corvus](https://github.com/eudoxia0/corvus)

~~~
uniclaude
Which is very interesting because statically typed!

Unlike Rhine, it's not Clojure inspired though.

------
charlieflowers
I think the holy grail may be the combination of working in a very expressive
high level language, but knowing and seeing exactly what that generates at the
low level. (And in those few cases where it matters, being able to
control/influence/change what it generates at the low level).

So this sounds pretty interesting.

~~~
shortsightedsid
FWIW, SBCL does exactly that. You can defun a function and disassemble it
right down to assembly. What this project does is slightly different which is
to use LLVM to achieve the same thing.

~~~
charlieflowers
Yeah I realize that, but good point. LLVM is very interesting to me, but
you're right that it's not as utterly low level as native assembly. It is the
most interesting assembly ("assembly-like"?) language to me at this time.

I didn't know SBCL did that. Cool.

~~~
enupten
All CL's have a #'disassemble, although the output of it is left undefined.

------
karavelov
What is the reason for using product of all primitive types for boxing instead
of tagged union?

~~~
artagnon
Because one type may use more than one field. Vectors and strings use the nr
field additionally, and functions use the vector/fenv field additionally.
Instead of creating a hierarchy, I figured a flat structure would be easier to
understand.

~~~
thinkpad20
I was going to ask about this as well. It seems like there's a lot of wasted
space in how things are represented. The first field already tells you what
type of object you're dealing with. Since you're using 64-bit integers, you
could represent pointers, bools, ints and floats all in the same memory space.
I guess there might be some types that use more than one field, but certainly
a bool is not going to.

There's also the issue of alignment with the usage of 1-bit and 1-byte
types...

------
dschiptsov
Lisp? So, it runs Maxima?

