freenode/lisp - IRC Chatlog
Search
3:23:39
beach
Thank you! Today, I think I'll work on an abstract for a recorded talks that I have planned to give in the context of phoe's new initiative (the name of which I forget).
4:42:14
beach
I didn't see it because 1. I am becoming more dyslexic over time, and 2. The spell checker doesn't recognize "sandboxing" anyway, so it was going to be flagged even with a `d'.
6:39:34
phoe
I didn't really think of anything more fancy since I don't think there needs to be anything more fancy
6:55:31
MichaelRaskin
beach: sounds interesting and useful! and it looks like your work on SICL bootstrapping is now close to making FCGE's available to people who are not going to write implementation internals.
6:58:17
beach
I just realized that a good existing implementation is not very far from using something like first-class global environments.
6:59:01
beach
I mean, it just keep the classes, the (SETF <mumble>) functions, the global value cells, the MAKE-INSTANCE, etc. Somewhere.
6:59:57
beach
So if they would just do the same for functions named by symbols, and global value cells, then they are half way there.
7:01:22
MichaelRaskin
I would be wary about that effect that «getting 90% right there takes 90% of effort… and so does the second 90%»
7:02:06
MichaelRaskin
I would expect a bit of special-case code for properly inlining the standard and defined-to-be-unredefinable functions like + — and like open
7:03:38
MichaelRaskin
It is very likely to make support of FCGE's with _different_ #'cl:open maintenance-intensive
7:03:52
phoe
package name, package predicate, value and function cells, symbol plist and flags that determine constantness, specialness, etc.., are all stored on the symbol
7:03:55
pjb
beach: (defun project-time (effort power) (if (< effort 0.00001) 0.0 (+ (* .9 effort power) (project-time (* 0.9 effort) power)))) (project-time 1.0 1.0) #| --> 8.999914 |#
7:04:44
pjb
https://www.volersystems.com/project-management/228-why-the-last-10-takes-90-of-the-time/
7:07:13
beach
pjb: I just don't see how first-class global environments would have any influence whatsoever on the applicability of that rule, nor on the inlining issues mentioned by MichaelRaskin.
7:07:39
beach
MichaelRaskin: It does, but now you are definitely talking about a subject unrelated to first-class global environments, right?
7:07:52
beach
I mean, I don't see how inlining has anything to do with first-class global environments.
7:08:19
pjb
beach: it's just a general rules. But I would say that it's quite possible that it doesn't apply in your case, given the steady pace your working at.
7:08:45
beach
pjb: I am sure it does apply, but I don't know how it is related to first-class global environments.
7:09:22
MichaelRaskin
For SICL, your inlining code is structured in a way that swapping out a single function should not be a problem
7:10:36
pjb
There are different environments, requiring different sandboxing. The CL environment (functions, variables, etc), the host file system environment, the network environment etc.
7:11:11
pjb
If you have an socket:connect, you may also want to sandbox your network node (use a different DNS, use virtual hosts, etc).
7:11:20
beach
MichaelRaskin: That's a narrow definition of "sandboxing". I consider it essential for a Common Lisp implementation to be safe that appplication code can not alter the code generator of the compiler without some additional manipulation. That's already sandboxing to me.
7:12:13
pjb
MichaelRaskin: with the tools provided by sicl, you can provide your own CL:OPEN to sandbox the file system.
7:12:32
MichaelRaskin
Well, sure, overwriting the compiled code cache does count as «special manipulation»
7:12:52
pjb
This would be required to avoid breaking out of the CL sandbox by generating a patched executable in the file system, and relaunching…
7:13:08
MichaelRaskin
pjb: yes, I have already said a few lines above that SICL is structured in a way that makes this a non-issue
7:14:15
MichaelRaskin
Protecting the code generator by default is what SBCL can do (and I expect that it does) via package locks
7:23:59
beach
phoe: Maybe I should not let you stream my presentation. I mean, first-class global environments are useless anyway, since the same effect can be had with package locks. Plus, it makes it necessary to change how inlining works, and it requires special definitions of CL:OPEN. Worse, it makes the 90/90 rule much worse.
7:25:27
MichaelRaskin
beach: it doesn't make 90/90 rule worse — I just said that 90/90 rule applies to implementing FCGE's in existing implementations without rewriting
7:26:44
MichaelRaskin
FCGE's in SICL, on the other hand, will be nice and useful and usable for defining a true sandbox for untrusted code with reasonable amount of work.
7:27:04
beach
This mode of discourse makes me tired, and I am not looking forward to answering remarks in real time when the presentation is streamed.
7:36:56
MichaelRaskin
FCGE's as you actually do them in SICL are definitely great and whoever tunes in given the abstract is likely to recognise that. Sorry for not delineating clearly that I only reacted to the claim about likely costs of implementing FCGE's in arbitrary implementations
7:38:55
phoe
my worry is about some compilers that open-code some functions regardless of their actual fdefinition, cl:car being the prime example
7:39:55
phoe
obviously it would be weird to modify cl:car in a FCGE, but the compiler is pretty much allowed to do the same with all CL symbols, given that they are immutable
7:40:30
phoe
that sounds like work required to make these implementations play nicely with FCGEs integrated into them
7:41:27
beach
Not SICL. CAR is defined like this: (defun car (x) (if (null x) x (if (consp x) (cleavir-primop:car x) (error ...)))) And that definition is taken from the first-class global environment.
7:42:31
MichaelRaskin
phoe: even open-coding unrelated to definition _could_ be structured in a way that you could easily reconfigure it given an FCGE … or ti could be structured otherwise
7:43:08
phoe
https://github.com/Clozure/ccl/blob/c444e10120159f9b388eb087699a7c28f2c0e384/level-0/l0-utils.lisp#L194
7:43:11
phoe
https://github.com/sbcl/sbcl/blob/28ddc79abc9f119e3b0e0b5ec9b74222366303e5/src/code/list.lisp#L30
7:43:30
phoe
and work because the compiler transforms the seemingly endless recursion into an open-coded operation
7:43:31
beach
phoe: And comparing CCL's definition of symbols, here is the one in SICL (yes, it is in Common Lisp): (defclass symbol () ((%name :initarg :name :reader symbol-name) (%package :initarg :package :reader symbol-package)))
7:45:03
phoe
beach: bad idea unless you consider the standard, which implies that this is allowed; and that the implementations have used that for decades since portable bootstrapping is a very new idea and FCGEs is a very very new idea
7:46:26
phoe
the currently alive implementations simply assume that the global environment is a singleton and are structured fully around that idea
7:46:31
beach
I am not saying it is not allowed. Just that I think it is a bad way of structuring an implementation, first-class global environments or not.
8:20:35
pjb
beach: the problem is not the definition of CAR, but that of COMPILE. (COMPILE '(lambda (x) (car x))) may do the same as (compile '(lambda (x) (cleavir-primop:car x)))
8:21:16
pjb
phoe: this means that if you modify any function in CL you must also modify CL:COMPILE to ensure open-coding the new definition or no open-coding. Also the compiler-macros!
8:23:30
pjb
beach: the compiler may also not special case the CL functions, but just inline them all. Or have compiler-macros on them to special case them. etc.
8:24:31
pjb
Or, said otherwise, it's not because an implementation such as sicl allows you to mutate operators in CL, that the CL rules about them don't apply.
8:24:51
pjb
ie. it's implementation defined, what happens if you fmutate CL:CAR and (COMPILE '(lambda (x) (car x)))…
8:30:30
beach
I hope I didn't imply any such thing. All I said was that CAR is not primitive enough to be considered a primitive.
8:32:58
pjb
other implementations could use a different definition for different safety levels, and therefore consider it a primitive (at least in (safety 0)).
8:33:02
beach
Plus, the Cleavir compiler can be customized, so it does not have cleavir-primop:car hardwired in it. It is just a default thing. Client code can have other definitions of CAR and define compiler methods to deal with whatever it defines CAR to be.
8:34:50
beach
Contrary to apparent appearances, I am not particularly interested in discussions like this.
10:27:01
beach
phoe: I am reading your code for the portable condition system. It looks quite good. Later, I might suggest some changes to it so as to make it easier to adapt to different clients. I would much prefer to use it as is, with customizations, as opposed to using a modified copy of it.
10:29:16
beach
One immediate thing I suggest would be to use disembodied documentation strings in a separate file, so as to allow client code to modify them more easily.
10:34:55
beach
Disembodied documentation strings also make the code less "nosy" to the maintainer, who presumably already knows what these functions are supposed to do.
10:46:38
phoe
beach: I'll need to make branches in this code anyway. One version, with inline documentation strings, will be intended for readers of my condition book; the other will be useful for integrating into e.g. SICL with docstrings moved aside and generic hooks into macroexpansions available - in the way you described where GFs can be called with custom clients.
10:47:19
phoe
That's required since we have two possible groups of audiences for the condition system: one who wants to understand how it works, and the other who wants to use it in real-life projects.