<pjb>
seok: the question is where you want to initiate the transfer of data from.
<pjb>
seok: also, note that for symbol, it's delicate, since Common Lisp symbols have a home package (symbol-package), and usually have uppercase names, while emacs lisp symbols don't have a home package, and usually have lowercase names.
<pjb>
seok: so it may be more convenient to avoid them.
<pjb>
seok: that said, swank\slime perform some conversion between CL symbols and el symbols, so that may be acceptable.
CrashTestDummy2 has quit [Ping timeout: 265 seconds]
CrashTestDummy has joined #slime
CrashTestDummy3 has quit [Ping timeout: 260 seconds]
OlCe has quit [Ping timeout: 240 seconds]
nicktick has quit [Ping timeout: 240 seconds]
<seok>
Oh you are here also pjb : ) thank you I will take a look
<seok>
I'm just getting started with emacs lisp and thought it would be cool to write macros from common lisp to elisp and vice versa
<pjb>
seok: yes, one can port emacs lisp code to common lisp and vice-versa.
<pjb>
seok: but there are sufficient differences to make it inconvenient to use the same code in both.
<seok>
Yes, there seems to be some difference in object types in CL and elisp
<seok>
I guess you can pass around hash tables but not some other values
<pjb>
seok: Apart from slime/swank RPC, you could consider integrating libecl (ecl) into an emacs plugin module (first step) and then integrating emacs library to give a good access to it from ecl.
<pjb>
seok: so we could just write emacs extensions in Common Lisp.
<seok>
Is this only applicable to ecl not sbcl ?
<pjb>
We would have a new type of function, common-lisp functions that would be evaluated thru ecl.
<pjb>
seok: ecl = Embeddable CL. It's designed for this purpose.
<pjb>
there's no libsbcl.so
<seok>
ah
<pjb>
so it's possible but it will require more work.
<seok>
I read in Elisp docs that it's not very fast
<seok>
Would it be able to cope with some heavier workloads in ECL?
<pjb>
seok: the alternative would be for me to have time to work on a C compiler targetting lisp, so that we may compile GNU emacs C code into a CL image. Then we would run emacs directly inside a lisp image, and we could call CL functions from emacs similarly.
<pjb>
seok: I would bet ecl is faster.
<pjb>
Well, there are works to compile to native code emacs lisp code, so it could be equivalent.
<seok>
"the alternative would be for me to have time to work on a C compiler targetting lisp" if you do this wouldn't we be able to run any C program in lisp image ?
<seok>
that's kind of a big deal
<pjb>
of course.
<pjb>
We would also compile C libraries instead of using FFI.
<pjb>
But I would expect that a lot of C code around uses too many UB to be able to work in the lisp image.
<pjb>
Only the cleanest C code would work.
<seok>
how fast do you reckon this C environment would be ?
<pjb>
As fast as any lisp function.
<pjb>
so between 0.9 and 2.0 times gcc speeds, with sbcl.
<seok>
2 times GCC speed? that's faster than other C compilers ?
<pjb>
sorry, I mean 0.9 and 2.0 times the times of gcc.