Hacker News Reader

Hacker News

Comment by rini17 | Hacker News Reader

Full thread

rini17

I'd prefer C++ interpreter written in Lisp...

View on HN

How about C?

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

https://github.com/vsedach/Vacietis

================

Vacietis is a C compiler for Common Lisp systems.

Vacietis works by loading C code into a Common Lisp runtime as though it were Lisp code, where it can then be compiled or evaled. The loaded C code has the same function calling convention as regular CL code and uses the same numerical representations. C memory is backed by regular Common Lisp arrays.

Vacietis comes with a libc implemented in portable Common Lisp.

I've always wanted one that worked by taking C code and outputting actual Common Lisp code. But I guess that is significantly harder since nobody seems interested in doing it.

I'm surprised that we don't see more compilers and interpreters written in Lisp, since people seem to believe that writing compilers in Lisp is easier than other languages. In fact most compilers and interpreters are written in C.

I don't think this is true anymore. From the TIOBE top 10 (that hallowed source of truth), I count only three languages whose main implementation is written in C (Python, PHP, R). Extending to top 20 only adds two more (Perl and Ruby). All of those are interpreters. Most compilers seem to be implemented in the language they are compiling. It appears that C++ is the most popular implementation language, although C is number two - but neither constitute a majority.

However my note is about Lisp in particular. Apart from a few cases, Lisp is little used to implement compilers for other languages.

we should have more static lang interpreters, with repls

I'll probably start a language war with this comment, I sure hope not.

I'm not exactly sure what you mean with just "static", I'm assuming static types. But wouldn't a language with static types and a repl not be as powerful as if it was dynamic instead? In the end, you want to be able to redefine everything via the repl in your runtime, and if there is types to be checked all the time and the compiler has to do extra steps for each eval, it'll get in your way and make it harder to monkey-patch things.

It is a bit more complicated. Sbcl, as an example, does check types on defun statements. Some it will just warn about, but some will prevent the completion.

It was so not about comparing, but learning c/c++ is often a less fun experience due to either the write / compile / debug cycle or the heavy tooling required.

A c/cpp repl would make people fiddle around and have a rapid intuition. Then they go without.

It exists!

Cling- https://root.cern/cling/ (and the earlier Cint- http://www.hanno.jp/gotom/Cint.html)

I used to occasionally use them for local experimenting with libraries and language features.

I don't think monkey patching is required. Although without a dedicated interpreter, you can just do what sbcl does under the hood and maintain what is essentially a tempfile and keep compiling that and reporting the output for every new line/block of code. (I don't know how sbcl actually works, being a lisp I presume it doesn't actually use a tempfile but instead a list in memory of the code the user submitted and then invokes the compiler as needed for new input including the output state as available symbols.)

A cycle that went something like:

    1. Write the line to a file
    2. Compile file with default flags
    3. Run binary in gdb causing gdb to dump certain interest info (stack info, variable contents, etc)
    4. Read the sections/symbols and merge this data into the gdb data (maybe get it from gdb)
    5. Dump this data into your reply and refresh waiting for user input.

You could have a few basic commands in the repl:

Modify the compiler args Add/remove/edit a line Attach gdb.

Emacs or vim could easily do this, and I suspect there are people who already do almost exactly this.

You could also just use any editor/ide with debug integration and keep a scratch file around...

> I don't think monkey patching is required

We're talking about a repl here, not just a basic shell. You'll need to be able to redefine functions and everything else at runtime so a repl is all you need to run your program. A lisp with a standard repl is running miles around any editor/ide with debugger support, as the workflow with repls, especially ones that can nest on exception and so on, is much faster.

Julia is kind of nice example of what’s possible with dynamic language and static types.

Julia does not (semantically) have static types. It just proves that you don't need static typing to have an incredibly rich and useful type system, and you don't need static types to have top notch performance.

Exactly, in case of Julia I think it all boils down to multiple dispatch and ahead-of-time compilation. But it's still dynamic!

Such REPLs exist since XDE for Mesa in Xerox PARC, and there are some for C++, C#, F#, OCaml, Haskell, Java, among others.

One example: https://gitlab.com/FascinatedBox/lily

Is that even possible? Practically, not theoretically.

Well, there's this [0] Scheme->C compiler, so if you were to port Cling [1] (C++ interpreter) to it, then you'd have achieved that goal pretty well. It'd be a large project, but practical to achieve.

[0] https://github.com/sph-mn/sph-sc

[1] https://github.com/root-project/cling

Of course it is. A friend of mine wrote a C99 interpreter in python in high school. He had the wonderful idea of not implementing any undefined behaviour that wasn't strictly necessary :) we used it to test our C code later on in the course.

It probably won't be very fast though. There are parts of C++ that doesn't map very well to common lisp, and which means some parts will have more overhead than necessary.

C99, sure. C++?

Of course it is doable. Nontrivial of course. C++ is probably not the language I would start with.

Very impressive for a high-schooler.

> He had the wonderful idea of not implementing any undefined behaviour that wasn't strictly necessary

What does this mean? It sounds like the way an ordinary C compiler works: it ignores the possibility of undefined behaviour occurring, as the C standard allows it to do this.

I just remember that it crashed if you tried to modify a string literal, which IIRC is undefined. And that it was very diligent about scope.

If you had signed integer over/underflow it wrote insulting error messages.

Probably not. Not in any language. If it was it would have been done a dozen times.

It has been done several times, at least.

http://www.hanno.jp/gotom/Cint.html

https://github.com/root-project/cling

https://www.softintegration.com

You can argue whether some of those are strictly interpreters, versus just a REPL hooked up to a compiler (as in the case of Cling). But they do exist.

it seems you could dlopen (etc) a compiled-in-a-repl code snippet, but it's seemingly not often thought of. not sure why. (I've done it, but just prefer straight compiling, as in "i am the repl".)

p.s. here's the most concise two refs i found by googling.

https://www.quora.com/What-is-the-purpose-of-dlopen-dlload-i...

https://man7.org/linux/man-pages/man3/dlopen.3.html

Not a complete transpiler, butI read about an interview about JVM implementation done on common lisp of Pascal Costanza and ability to port all things then supported in Java to lisp[0].

"...I decided to implement a Java Virtual Machine in Common Lisp - under normal circumstances, I wouldn't have dared to do this, because this is quite a complex undertaking, but I had read in several places that Lisp would be suitable for projects that you would normally not dare to do otherwise, so I thought I would give it a try. Over the course of 8 weeks, with something like 2 hours per day, or so (because I was still doing other stuff during the day), I was able to get a first prototype that would execute a simple "Hello, World!" program. On top of that, it was a portable (!) just-in-time compiler: It loaded the bytecode from a classfile, translated it into s-expressions that resemble the bytecodes, and then just called Common Lisp's compile function to compile those s-expressions, relying on macro and function definitions for realizing these "bytecodes as s-expressions." I was really impressed that this was all so easy to do.

The real moment of revelation was this: to make sure to reuse as many of the built-in Common Lisp features as possible, I actually translated Java classes into CLOS classes, and Java methods into CLOS methods. Java's super calls posed a problem, because it was not straightforward to handle super calls with plain call-next-method calls. Then I discovered user-defined method combinations, which seemed like the right way to solve this issue, but I was still stuck for a while. Until I discovered that moving a backquote and a corresponding unquote around actually finally fixed everything. That was a true Eureka moment: In every other programming language that I am aware of, all the problems I encountered until that stage would have required a dozen redesigns, and several attempts to start the implementation completely from scratch, until I would have found the right way to get everything in the right places."

[0] - lisp-univ-etc.blogspot.com/2012/04/lisp-hackers-pascal-costanza.html

Reply on news.ycombinator.com