freenode/#sicl - IRC Chatlog
Search
4:28:26
no-defun-allowed
What microphone did you use to record voiceovers for the online presentations?
4:33:48
no-defun-allowed
Oh, because I'm trying to use OBS with a studio microphone, and the gain that I used to produce an acceptable volume doesn't seem have been applied in the recorded video.
4:35:13
no-defun-allowed
Yes, but the noise filter somehow still got applied, and most of my words were cut out, so I have to re-record.
4:36:03
beach
Yes, I see. :( Having to re-record happens to me pretty much every time, for one reason or another.
5:09:19
no-defun-allowed
Alright, I disabled the noise filter and now I just have to adjust the volume when I edit the clips together.
6:21:41
beach
With respect to my series of presentations for the online Lisp meeting, it is interesting to me that several people suggest better alternatives to C. I recently received email from Clive Tovero suggesting PreScheme and Scheme86. So I observe that there is still this widespread idea that a Common Lisp implementation must be written in something other than Common Lisp.
6:28:43
beach
Now, jackdaniel said that he likes the fact that ECL can be built on a system that has nothing other than C. I guess the only way to address that restriction is some kind of BOCL ("Bootstrap Common Lisp) idea, i.e. an implementation that only requires C, but that is designed with the sole purpose of bootstrapping "production" Common Lisp implementations.
6:30:04
beach
And then it is going to boil down to what is considered "source code". In other words, does the C source have to be written by hand, or can it be generated.
7:54:39
jackdaniel
mind, that I've added "given ecl's niche", in other words because its runtime is build on top of C's runtime
7:55:35
jackdaniel
so it is to some degree a pisix common lisp (if we acknowledge that posix is basically c plus os library with c api)
8:00:34
beach
That doesn't stop me from trying to come up with ideas to make ECL and Clasp maintenance burden lighter.
8:11:30
beach
For example, I suggested a long time ago that Clasp implement the possibility of saving and loading the image, because that would cut down on the additional code meant to make startup faster. It appears that this possibility is now about to be implemented.
12:35:06
pjb
beach: perhaps better than a C->CL->CL bootstrap, would be a CL cross compiler. Ie. if we're able to compile with a CL running on a system A a binary CL targetting a system B, then we don't need to bootstrap from different language anymore.
12:36:08
beach
And that is precisely what SICL is doing. But jackdaniel wants ECL to be possible to build on a system that has only C.
12:44:07
no-defun-allowed
Not exactly relevant is the way Squeak Smalltalk was bootstrapped, which I find a bit fascinating: http://ftp.squeak.org/docs/OOPSLA.Squeak.html
12:44:39
jackdaniel
if I understand correctly, you want to create a separate cl implementation for a sole purpose of bootstrapping from c (that is c -> cl -> cl); I think that ecl, as bootstrapped from c, already fills this gap so the task would be more or less opening the unlocked door. as of transpiling CL -> C, ecl's compiler also is capable of doing that, however it targets its own C-ish runtime of course
12:46:31
no-defun-allowed
That was produced by passing the source code for the interpreter in the Blue Book into a Smalltalk-to-C translator, as well as a small amount of C code for interfacing with the operating system. But HIR is much more complex than the subset of Smalltalk used in the interpreter, from memory.
12:46:46
beach
jackdaniel: Me? Yes, but the C code of ECL is more complicated than a BOCL would need, because ECL is designed with performance in mind. A BOCL could be much simpler, and then also simplify the C code of ECL, and even eliminate a lot of it.
12:47:46
beach
pjb: If you look at the channel logs, I asked the question (without expecting an answer) whether C code that is generated was acceptable as counting as "source code".
12:49:13
beach
shka_: But it has to be maintained. And, as I said, I am imagining ways of decreasing the maintenance burden of ECL and other Common Lisp implementations.
12:49:41
beach
jackdaniel: If there is a reader and/or an evaluator written in C, then to me, that is already complex.
12:50:33
no-defun-allowed
And then the Smalltalk I hacked on a Wii is someone's port of that interpreter from said Book to C++, with my own I/O code and some tweaks for endianness. But that interpreter is written (in my opinion) in a restricted way, so that it can be translated into a less expressive language.
12:50:58
beach
no-defun-allowed: HIR could definitely be translated to C. After all, it can be translated to assembly.
12:51:49
beach
no-defun-allowed: And, again, it is unclear whether generated code would count as "source code". It does not, according to the definition by the FSF, for instance.
12:55:11
no-defun-allowed
Defining that generated code is source code would probably break restrictive licenses that are used for, say, JavaScript libraries which are transmitted in obfuscated and compressed form, so it would be wise not to define it like that in the general case.
12:56:23
beach
Yeah, and I am pretty sure that jackdaniel would consider that solution unacceptable, or else, he would have thought of it before.
12:56:35
pjb
beach: "maintainable code" or not. But what's generated should not be considered as source. It can be considered as an intermediate representation compilable on a target system.
12:57:58
beach
But I am not going to pursue it. It is clear to me that jackdaniel is fine with the way ECL is currently written. So consider it as just a thought experiment.
12:58:17
no-defun-allowed
No doubt that HIR could be translated to C, but that would require more of a compiler than Squeak did...the interpreter is written with simple control flow and mostly works on words and vectors of words.
12:59:46
beach
I do think the idea of BOCL is interesting though. Write a Common Lisp in C, but in a way that makes it as easy as possible to maintain, rather than fast or whatever.
13:00:04
no-defun-allowed
So I wouldn't think it to be a SICL-y thing to do; but I don't know if that's a necessity in this context.
13:01:04
no-defun-allowed
I had better head out as well; I will reread this tomorrow and will see if anything else comes to mind.
13:09:04
MichaelRaskin
Speaking of layers-of-expanding-languages and bootstrap, I think GNU Guix people think that even C bootstrap is best implemented as a multi-layer process. Think, as in «have implemented such a multi-stage bootstrap».
13:11:13
jackdaniel
I imagine troubleshooting malfunctioning transpiled code could be harder to debug (the bug may be in Common Lisp reader source, in the transpiler source, or there might be some bootstrapping issue of the reader itself - i.e that it depends on something what is not available yet in the system)
13:11:50
jackdaniel
also, depending on such transpiled code may be a subject of metastability issues when indeed bootstrapping from i.e gcc
13:13:46
jackdaniel
in other words, it is not given that such dependency won't add /more/ complexity instead of removing it
13:14:05
pjb
jackdaniel: of course, you need to locate the bug, but it's not difficult to debug. As always, you need to determine if it's the "current" source that is in error, and if so, correct it and its producer.
13:14:34
pjb
jackdaniel: if you're a good programmer, you know what I mean: when you debug, you not only correct the bug, but you correct yourself to avoid producing the same bug again!
13:15:14
jackdaniel
maybe I'm a bad programmer, because sometimes understanding the issue takes me days or even weeks
13:18:57
jackdaniel
I'll stick to the interpretation, that I'm a bad programmer, if that's the implication of not finding "fixing bugs" easy. most bugs I encounter are architectural issues and I don't think tooling is much of help when you need to think of an architectural change which a) won't introduce regression, b) will fix the issue
13:21:19
MichaelRaskin
beach: just as you discussed in your talk — inner layers are more limited, lacking some of abilities.
13:30:25
beach
MOP question: I am reading the MOP page on Initialization of Class Metaobjects in chapter 6. It says that when the class is initialized, a default superclass may be added (as expected). But it doesn't say that when the class is reinitialized. So if I create a standard class with direct-superclasses being the empty list and then I reinitialize it with an empty list, is the class no longer a subclass of standard-object?
13:33:06
beach
SBCL still includes STANDARD-OBJECT if I do (reinitialize-instance (find-class '... :direct-superclasses '()))
13:35:13
pjb
My understanding is that it could be done lazily. So a change of the direct-superclass list can have no (immediate) effect.
13:36:00
beach
I think the page I am talking about makes that clear. Except I think it has an error on it.