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)))…