freenode/#lisp - IRC Chatlog
Search
13:49:30
dlowe
I am a little concerned, though, that global environments are too big a hammer for sandboxing
13:50:58
dlowe
whereas importing something into a global environment also introduces all its transitive dependencies
13:53:23
beach
I am planning to import just the functions COMPILE and COMPILE-FILE from the compiler first-class global environment into the default first-class global environment.
13:56:42
dlowe
okay, so I import COMPILE from CL to my global environment FOO, and call COMPILE from within FOO. Either a) COMPILE runs in FOO and can't access its dependencies or b) COMPILE runs in CL and macros have complete access to CL
13:58:02
dlowe
Okay, where have I got astray? You can point me at a paper if it's easier than explaining on IRC
14:00:09
pjb
dlowe: also, environment is an overloaded term in the hyperspec. There's at least three meanings to it.
14:00:35
beach
dlowe: You are assuming that function lookup is done at run-time. That would be too expensive. Instead, when code is loaded, it is "tied" to a particular environment. After that, a function such as COMPILE can be imported to other environments without the callees being imported.
14:05:06
pjb
beach: wouldn't a mere map of names to packages be enough for environment objects? If you put bindings in your environment objects, I think you'd want to provide a way to let user programs put their own bindings there too.
14:07:36
pjb
For example, if I want to bind strings to value slots thru a hash-table, I may want to do that thru different hash-tables depending on the environment.
14:08:19
pjb
Or perhaps thru the same hash-table, depending on the environment. I mean, several types of lisp objects have slots, which can serve to bind values.
14:09:16
beach
I don't see how a mapping from names to environments would be enough for the kind of functionality I am after.
14:18:19
pjb
For sandboxing, you may want to substitute CL stuff. If you use CL:COMPILE, you may not be able to substitute what you need to substitute. First, CL:COMPILE is allowed to opencode any CL operator. This means that (cl:compile nil '(lambda () (cl:open "foo"))) will be able to implement the semantics of the native cl:open, even if you define a different cl:open binding in the global environment.
14:18:46
pjb
beach: Said otherwise, once you introduce your environments, you need to provide your own compile function to ensure that it's used.
14:21:20
beach
But it is still the FDEFINITION of the name CL:COMPILE in some first-class global environment.
15:20:30
jcowan
Part of the problem is that CL doesn't allow renaming of either packages or the symbols in them. In better (ahem) module systems, either or both of these may be possible.
15:24:03
heisig
You can also transfer the symbol value, symbol function, symbol plist and all documentation to another symbol via SETF.
15:25:02
jcowan
Passing everything to another symbol doesn't leave the identity visible to compilers, though: (define foo (x) (car x)) might or might not be inlined.
15:29:22
heisig
Oh, right. To do so, you would also have to migrate all declarations and the inline information on that symbol. That is not possible, at least not in portable code.
15:30:07
heisig
But I wouldn't recommend this way of 'renaming' symbols anyway. I just wanted to point out that it is possible.
17:12:54
jcowan
Depends on if you think of it as a symbol (runtime object) or an identifier. In the latter view you are saying "In this scope of code foo (imported from module baz) will be known as bar, but it is still really foo."
19:08:23
aeth
beach: Is there ever a chance that SBCL and CCL get first class global environments or is it too tied to SICL?
19:10:18
beach
I have no control over SBCL or CCL. It is highly unlikely that their respective maintainers will accept that work though.
19:11:27
beach
Maybe, just maybe, after SICL is finished and people understand the value of having first-class global environments it could change.
19:11:52
beach
I'm off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+1).
19:12:19
aeth
I'm just thinking about it being a similar situation to e.g. package local nicknames, which were around for forever, but that most people didn't use until (nearly) everyone supported it.