6 ms·

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

by rini17 6y ago

sillysaurusx 6y ago
Is that even possible? Practically, not theoretically.
- shakna 6y ago
  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 https://github.com/sph-mn/sph-sc [1] https://github.com/root-project/cling https://github.com/root-project/cling
- bjoli 6y ago
  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.
  - sillysaurusx 6y ago
    C99, sure. C++?
    - bjoli 6y ago
      Of course it is doable. Nontrivial of course. C++ is probably not the language I would start with.
  - MaxBarraclough 6y ago
    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.
    - bjoli 6y ago
      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.
- postalrat 6y ago
  Probably not. Not in any language. If it was it would have been done a dozen times.
  - swiftcoder 6y ago
    It has been done several times, at least. http://www.hanno.jp/gotom/Cint.html http://www.hanno.jp/gotom/Cint.html https://github.com/root-project/cling https://github.com/root-project/cling https://www.softintegration.com 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.
- jjtheblunt 6y ago
  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-in-C-programming-in-Linux-environment https://www.quora.com/What-is-the-purpose-of-dlopen-dlload-i... https://man7.org/linux/man-pages/man3/dlopen.3.html https://man7.org/linux/man-pages/man3/dlopen.3.html
- rottc0dd 6y ago
  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
agumonkey 6y ago
we should have more static lang interpreters, with repls
- capableweb 6y ago
  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.
  - taeric 6y ago
    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.
  - agumonkey 6y ago
    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.
    - rlonstein 6y ago
      It exists! Cling- https://root.cern/cling/ https://root.cern/cling/ (and the earlier Cint- http://www.hanno.jp/gotom/Cint.html http://www.hanno.jp/gotom/Cint.html) I used to occasionally use them for local experimenting with libraries and language features.
  - emidln 6y ago
    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...
coliveira 6y ago
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.
- Athas 6y ago
  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.
  - coliveira 6y ago
    However my note is about Lisp in particular. Apart from a few cases, Lisp is little used to implement compilers for other languages.
flubert 6y ago
How about C? https://news.ycombinator.com/item?id=25531871 https://news.ycombinator.com/item?id=25531871 https://github.com/vsedach/Vacietis 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.
- ksaj 6y ago
  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'd prefer C++ interpreter written in Lisp...

by rini17 6y ago

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

sillysaurusx 6y ago

Is that even possible? Practically, not theoretically.

shakna 6y ago
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 https://github.com/sph-mn/sph-sc [1] https://github.com/root-project/cling https://github.com/root-project/cling
bjoli 6y ago
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.
- sillysaurusx 6y ago
  C99, sure. C++?
  - bjoli 6y ago
    Of course it is doable. Nontrivial of course. C++ is probably not the language I would start with.
- MaxBarraclough 6y ago
  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.
  - bjoli 6y ago
    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.
postalrat 6y ago
Probably not. Not in any language. If it was it would have been done a dozen times.
- swiftcoder 6y ago
  It has been done several times, at least. http://www.hanno.jp/gotom/Cint.html http://www.hanno.jp/gotom/Cint.html https://github.com/root-project/cling https://github.com/root-project/cling https://www.softintegration.com 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.
jjtheblunt 6y ago
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-in-C-programming-in-Linux-environment https://www.quora.com/What-is-the-purpose-of-dlopen-dlload-i... https://man7.org/linux/man-pages/man3/dlopen.3.html https://man7.org/linux/man-pages/man3/dlopen.3.html
rottc0dd 6y ago
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

agumonkey 6y ago

we should have more static lang interpreters, with repls

capableweb 6y ago
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.
- taeric 6y ago
  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.
- agumonkey 6y ago
  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.
  - rlonstein 6y ago
    It exists! Cling- https://root.cern/cling/ https://root.cern/cling/ (and the earlier Cint- http://www.hanno.jp/gotom/Cint.html http://www.hanno.jp/gotom/Cint.html) I used to occasionally use them for local experimenting with libraries and language features.
- emidln 6y ago
  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...

coliveira 6y ago

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.

Athas 6y ago
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.
- coliveira 6y ago
  However my note is about Lisp in particular. Apart from a few cases, Lisp is little used to implement compilers for other languages.

flubert 6y ago

How about C? https://news.ycombinator.com/item?id=25531871 https://news.ycombinator.com/item?id=25531871 https://github.com/vsedach/Vacietis 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.

ksaj 6y ago
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.