Hylas-Lisp - A JIT-compiled Lisp targeting LLVM | Hacker News Reader

Hylas-Lisp - A JIT-compiled Lisp targeting LLVM

github.com

96 pointsagumonkey32 comments

I like this trend toward wide-spectrum languages. For other recent examples, see Terra and Nimrod (I realize Nimrod has been around for a while, but seems like it's recently gaining significant popularity).

It's nice how closely languages like Python and Lua and integrated C through their various FFIs (particularly Luajit's FFI), but it's still a huge pain in the ass to continuously context switch between languages whenever you have to drop down and do something low-level, or to improve performance. I hope at least one of these languages catches on in the wider programming community so I'll have a chance to use it in "real world" programming.

How does this compare with extempore? More specifically xtlang which seems to have similar goals. http://extempore.moso.com.au

Wow, this blows my mind up, thanks for posting. Immediately had a look if it was already discussed on HN and to my surprise it went completely unnoticed! So here the links:

https://news.ycombinator.com/item?id=5397123

https://news.ycombinator.com/item?id=5125339

After having slept over it I re-posted it on HN, because I am convinced it needs more attention. So in case you stumble over this comment, the new post is: https://news.ycombinator.com/item?id=6640244

as people said on reddit, the CL timing on the chart is "bogus" http://www.reddit.com/r/lisp/comments/1pgdyo/hylaslisp/

Indeed (author here). Aside from Fibonacci being a worthless benchmark, the Common Lisp code was unoptimized and running on CLISP(!) on Windows(!!). Moreover, it was from an old version of the compiler. The benchmark just sat there for a while as I rewrote it from C++ in Common Lisp, and it was stupid of me to let it hang around for so long.

side note: as long as your jitted-llvm time is correct, then it speaks for itself, people shouldn't really care how much faster hylas is compared to any lisp implementation (even though it's in the chart).

ps: I really like the WSL side of things, as a lispos/lispmachine daydreamer, I'm impatient to see bare metal lisp systems running (fast).

Yes, it's strange to benchmark a standard and not an implementation. Besides, timing in well-known implementation such as SBCL looks much better here than in the chart.

How hard is it to extend 'foreign' to other languages besides C/C++? If this is possible, a guide for doing so would be invaluable. It would be awesome if there was a lisp that could compile directly to LLVM using native objectiveC libraries on iOS. VERY cool work, thanks for sharing!

That was part of my original intention. The reason 'foreign' takes C as its first argument in the examples is so I could eventually add support for binding mangled C++ functions mangled through Clang/GCC (Which luckily use the same mangling scheme).

> It would be awesome if there was a lisp that could compile directly to LLVM using native objectiveC libraries on iOS.

You might be interested in http://programming.nu/

for Lisp on iOS & Android see https://wukix.com/mocl

intro talk (at Bay Area Lisp Revival): https://wukix.com/mocl-balisp8

I still remember when you guys initially posted this on HN a couple of months ago. I found it interesting though one dominant criticism was that your site does not deliver enough information about the product to form an informed decision. Especially not given the steep price. I've played with NU, I've played with Clozure, I've played (a bit) with ClojureC, but they all felt half-finished or I couldn't get into them. Mocl still sounds kinda good, but your site looks just like it looked a couple of months ago, no information on why exactly I should spend that much money, or how it performs in comparison to other solutions etc.

I think it would be great if you could put way more code and docs there.

You may want to check out the sample code on our Github, https://github.com/Wukix, which wasn't available at launch. Working on adding more. Appreciate the feedback!

Thanks! Will look into it.

Am I missing something with the "Hylas" name vs. the lambda & gamma initials within the project logo?

The inverted lambda was supposed to look like the letter 'y'.

I like to pretend it looks more like 'hylas' than 'aylas'.

Yes, the letter 'y' is called '(G/Y)amma' im greek. Why 'Hylas' for me it reads like 'Lylas', considering that λ is the greek 'L'?

eudox, do you have a use case for this Lisp or is it more of an intellectual exercise?

I feel there is a spot between the performance and control of low-level languages and all the tremendously useful features of high-level languages. What I basically wanted was "C with Lisp macros". I think Rust is the closest language, ideologically, to Hylas.

There is no specification or anything very formal laid out except for a couple .md files in the docs folder. The language has evolved and changed a lot over the past year (Everything from the comments to the type system has changed), and is nowhere near prod-ready, but I want to eventually put it to practical use.

This reminds me a lot of GOAL, the in-house videogame development language that we used to use at Naughty Dog. It had a LISP syntax and feel - complete with awesome metaprogramming and on-the-fly relinking - but the runtime was much closer to a low-level C/C++. In fact, you could even drop into MIPS asm in the middle of a function.

Coming from a mostly C/C++ background, it was an eye-opening experience, and I'm definitely a fan of languages other than C for performant code.

C and later on C++ just got widespread due to UNIX's adoption at the enterprise, before that, there were quite a few systems programming languages around.

Of course, youngsters nowadays tend to think only C and C++ play on that league.

Interesting. Which ones in particular were popular? And what do you consider a "systems programming language"? As I understand it, a systems programming language is a language that can be used to implement an operating system. C was the first high-level language to be used in this way.

Algol 68, PL/I, PL/M, Ada, Modula-2, Modula-3, Oberon, Extensions to Pascal like Apple Pascal and Turbo Pascal, Lisp

I've heard about that and it sounds awesome. Can you say anything more about its design and syntax? For instance, I've heard that you could do manual memory management in GOAL. How was that accomplished?

It's been a while, so my memory's a little fuzzy. If I remember correctly, all the code was s-expressions, piped through a scheme (?) preprocessor, and then into the compiler. Many of the basic language constructs were actually macros.

The lower-level language itself was statically typed, and supported pointers and arrays as native types - identical to their C equivalents. Classes either derived from "structure" (unboxed) or "boxed". The boxed types had a class pointer, much like a C++ vtable ptr, but with some more useful introspective data attached.

Runtime linkage was mostly accomplished by patching types' method slots and/or patching a global symbol table. The compiler talked to a MySQL database which was shared by the whole company, so that symbols wound up having unique and consistent ids across all machines. The "listener" ran on a PS2 devkit, and essentially just accepted object code to link and execute. The REPL worked by having the compiler compile each expression, squirt the MIPS object code over to the PS2, have the PS2 link and execute it, and return a result, which the compiler would then print (possibly peeking into the PS2's memory in order to display more useful information). Similarly, you could place your cursor inside a block of code, hit CTRL+T and have just that function/method updated on the target. (This was back when edit-and-continue was still something of a novelty!)

The ABI was close enough to C that GOAL and C could call each other almost directly (the MIPS GP register had different meanings in GOAL vs C code, and so had to be patched up).

You could also pretty much mix GOAL and assembly, and we frequently did. GOAL's backend was never going to be as efficient as gcc's, but the massive increase in productivity it provided meant that we could devote much more time to optimizing the stuff that really mattered.

I think Andy Gavin's on here somewhere - he should really write an article about it if he hasn't already :)

Any chance that you have seen Dylan, http://opendylan.org/ ?

I've heard of it but never took a hard look at it. The one thing that's interesting about it to me is that it's a Lisp with "normal syntax", which is people's main complaint about Lisp, yet it hasn't exploded in popularity the way one might think it would.

Just a thought.

How did you go from "C with macros" to Dylan? I love dylan but its main draw is its object system, not macros or metal.

C could have meant a different syntax. Dylan is pretty well known for having macros without having s-expressions. And some pretty low level code can be written in Dylan. There's been some low level networking code by some Germans, as well as large parts of the Dylan runtime, including byte-level layout of method dispatch data. Looking through what he has so far in his repo (a quick look), a lot of it is similar to what we have in subject matter.

I want C (Objective-C) with Lisp macros too. Are you looking dor contributors?

> I want C (Objective-C) with Lisp macros too.

You might be interested in http://programming.nu/

Reply on news.ycombinator.com