libera/#commonlisp - IRC Chatlog
Search
5:53:30
nij-
For example, after I `(ql:quickload :rutils) (in-package :rtl-user) (named-readtables:in-readtable rutils-readtable)`,
6:05:22
beach
Functions like COMPILE-FILE and LOAD bind *READTABLE*, so during compilation or loading, even if you alter the readtable, its old value is restored after compilation or loading.
6:06:32
beach
And, no, there is no mechanism to change the readtable according to the current package. There are two different variables: *PACKAGE* and *READTABLE*.
6:10:31
nij-
I see. Yeah after playing it more, I almost came to the conclusion that it's not meant to be used interactively.
6:12:10
nij-
I just add (setq *readtable* my-readtable) in the beginning of the file, and (setq *readtable* *old-readtable*) in the end of the file?
6:13:02
beach
You don't have to set it back. Like I said, COMPILE-FILE and LOAD do (LET ((*READTABLE* *READTABLE*)) ...) around the reading of your file.
6:14:54
nij-
beach, sorry, do you mean (let ((*readtable* *my-readtable*)) <insert the codes in the file>)?
6:16:01
beach
Check this example: (defparameter *x* 10) then (let ((*x* *x*)) (setf *x* 20)) then *x*
6:16:48
beach
That is what COMPILE-FILE and LOAD do, so you can safely assign to *READTABLE* in the file.
6:17:50
nij-
so do you mean (let ((*readtable* *readtable*)) (mutate *readtable*) <insert the codes in the file>)?
6:19:08
nij-
I use asdf without touching compile-file and load. But lemme do a quick experiment. Thanks :D
6:19:10
beach
Therefore, it is safe to assign to *READTABLE* in the file, just like you do (IN-PACKAGE...) in the beginning of the file.
10:14:01
minion
Josh_2: please look at universal greeting time: It is always morning when a person enters a channel, and late night when they leave. You may want to read http://www.total-knowledge.com/~ilya/mips/ugt.html for further information
12:16:26
Equill
Good point with the cake analogy: maybe what this thing needs is some brandy. I mean, what's the worst that can happen?
12:18:54
hayley
"By now, my remaining readers are wondering what I’ve been smoking. Well, I don’t smoke, but red wine is good for you."
12:18:55
Equill
Oh man, I've had that moment. Reading through some old code and thinking "was I *drunk* when I wrote thi... oh crap, now I remember. Yes, I was."
12:35:35
nij-
I heard the following: C is a lingua franca, so being able to FFI with C makes CL able to communicate with almost all langs.
12:37:06
nij-
That makes C an "inferior", in the sense that C has not much freedom to do whatever it wants, including talk to the third language X.
12:37:51
nij-
In the case where the thid language X is embedded in C (e.g. X = Python), it is easier to let CL and X communicate.
12:37:53
jackdaniel
usually a ffi has two aspects: calling foreign functions and creating callbacks that may be called by foreign functions
12:38:13
nij-
But other languages do not necessarily embed in C. I thus wonder how we can use CFFI to do FFI with other langs.
12:38:16
jackdaniel
when you want for some c function to call your cl function, you define a ffi callback and pass it to the foreign world
12:39:24
jackdaniel
C ABI is omnipresent, that's why having FFI allows you to interact with other programs exposing C ABI (be it a program written in C or in Python) - ABI is mostly about how to call things and retrieve values
12:40:59
nij-
But for C to work in CL, it basically got embedded as a process in CL. In this case, even if lang X has a nice CFFI, it cannot embed the same C process in itself.
12:41:53
jackdaniel
you may compile CL to a shared library (be it ecl or sbcl recently) and export an interface following the C ABI convention
12:42:22
jackdaniel
then some program (i.e written in FOOLANG) may load that shared library and call functions exported using that interface as if these were C functions
12:42:36
nij-
Oh I see. So first have CL load a C shared library. And compile this into another shared library to be loaded by X?
12:43:47
jackdaniel
I don't know what you want to achieve, but it may be that you have compiled CL library to a shared object, you dlopen it from FOOLANG program and call the function cl_load_ffi, and then that CL library dlopen's libraries it uses itself
12:45:57
nij-
With this method, to let CL and FOOLANG interopt, one needs to write many C wrappers, and the CL objects and X objects should be translated via the semantics of C.
13:08:35
nij-
But then I wonder if interopting with C++ is the final purpose, why not just use FFI, and why bother creating a whole new implementation in the first place?
13:09:49
beach
nij-: In the case of Clasp, drmeister had a large number of existing C++ libraries he wanted to use from Common Lisp.
13:11:44
jackdaniel
nij-: kind folks on #clasp already explained to you why CL--C--C++ is suboptimal
13:12:24
nij-
jackdaniel - During the last time I was there, at the end we got an inconclusive answer, no?
13:14:12
nij-
jackdaniel I may lack experience or high IQ to understand immediately, which may resulted in that you think I wasn't listening, but by all means that's not the case.
13:15:10
nij-
Anyway, if asking very stupid question is frowned upon in any channel, please feel free to let me know. I will confrain myself. Sorry about that.
13:15:37
beach
I suspect the main difficulty with making different languages collaborate is not to have them communicate, but to resolve semantic differences.
13:15:55
jackdaniel
person asking the same (suggestive) question a few times despite being explained that this is not the case is a red flag to me ,)
13:16:07
nij-
I think in that conversation one thing is clear to me: There are many ways to achieve the goal, and clasp chooses one based on drmeister's experience. I have failed to understand a concrete reason, jackdaniel
13:16:43
jackdaniel
one from many reasons mentioned during the conversation back then is defining common lisp classes that are seen by c++ as c++ classes and vice versa
13:18:17
hayley
I agree, "CL objects and X objects should be translated via the semantics of C" takes much effort, and I do not like the semantics of C very much either.
13:18:26
jackdaniel
it can't, that's one of these semantic difference beach mentioned above - you can't represent a common lisp class with C semantics
13:20:33
nij-
At the end everything is 0 and 1. I can't imagine why an approach will never work to create the abstraction that makes C++ classes be "seen by" CL classes and vice versa.
13:20:35
hayley
For (defstruct foo bar) I wouldn't expect struct foo *f; ... f->bar; unless we are using SBCL bootstrapping magic.
13:21:10
nij-
jackdaniel one thing I'd like you to acknowledge is that the conversation may be clear to you but may not be clear to someone that's dumber than you
13:21:29
hayley
Because, actually, when it comes to C++ and CL, both systems deal with objects that are more complicated than 0s and 1s.