freenode/#sicl - IRC Chatlog
Search
4:48:47
no-defun-allowed
What does an environment which has been restricted for MACROLET expanders provide which the global environment does not?
5:06:27
no-defun-allowed
Hm, SICL/Code/Boot/environment.lisp has a method for RESTRICT-FOR-MACROLET-EXPANDER which does nothing.
5:20:05
beach
Aha, so the restriction doesn't work, which may be the reason this bug has not been detected.
5:26:28
beach
I am still not convinced about the quote we added the other day, but if we can get the thing past MIR-to-LIR, that problem can wait until later. Though if you feel like looking into it, that's fine as well.
5:27:01
no-defun-allowed
Currently I have modified TRUCLER:QUASI-CLONE to break when a restricted environment is cloned and the new environment isn't restricted, and there are such cases.
5:29:35
beach
Is it OK with you to dive into things in this level of detail? I mean, I am delighted that you do this because it would mean more people know this stuff. But you should tell me if you would rather do just register allocation.
5:30:35
no-defun-allowed
But that is incorrect when we attempt to describe variables that should be available to the expander function, such as the implicit #:whole and #:environment arguments.
5:32:29
no-defun-allowed
Although the error would be less specific, restricting could also be done by removing lexical variable and local function descriptions from the environment.
5:34:16
no-defun-allowed
It is done by setting a RESTRICTED-P slot in the environment, and every DESCRIBE-thing method checks that it does not return a lexical variable or local function description from a restricted environment.
5:35:32
no-defun-allowed
A quick test with this implementation of restricting produces the error "The variable X is unbound." on the example of (let ((x 2)) (macrolet ((f () x)) (f)))
5:38:43
no-defun-allowed
Yes, though detecting that the macro function attempted to use a local variable would be nice. SBCL mentions it: "The variable X is unbound. It is a local variable not available at compile-time."
5:39:41
beach
Yes, that would be better. The most important part is detecting a problem so that bugs don't propagate, though.
5:53:59
no-defun-allowed
It doesn't seem right still. Currently, the macro function is evaluated in the restricted local environment. But I don't know what local information is used in compiling the macro function.
5:55:56
no-defun-allowed
The HyperSpec says "Declarations and macrolet and symbol-macrolet definitions affect the local macro definitions in a macrolet, but the consequences are undefined if the local macro definitions reference any local variable or function bindings that are visible in that lexical environment."
5:58:37
no-defun-allowed
Now I see that we keep local macro definitions, so that (macrolet ((f () 'x)) (macrolet ((g (x) (f))) (g 5))) would work.
6:10:30
no-defun-allowed
By the way, that method in SICL/Code/Boot/environment.lisp is for restricting a global environment, which is correct to do nothing.
6:21:44
no-defun-allowed
SICL bootstrapping still works (without converting past HIR). I suppose I should see if removing that quote now causes compilation to signal an error.
6:23:44
no-defun-allowed
There are a very large of warnings now of the form " WARNING while evaluating compile-time side effect: Unknown variable #:ARGUMENTS-nnn"
6:25:12
no-defun-allowed
Yes, it is better than producing broken HIR. Bootstrapping still "succeeds" in the sense that it returns a BOOT object, but there are enough warnings that one would think something is up.
6:27:07
no-defun-allowed
Yes, there are at least dozens of new warnings about that variable being unknown.
6:30:30
no-defun-allowed
Here is a fork of Trucler with the new restricting technique: <https://github.com/no-defun-allowed/Trucler>
6:34:16
beach
But we agreed that the ultimate solution would be to use the old technique, but to use it correctly, right? So as to get better error messages?
6:35:46
no-defun-allowed
I don't think so, because we cannot distinguish which lexical variables and other local information is restricted and which isn't with just RESTRICTED-P.
6:37:09
beach
Well, in that case, Trucler should probably receive a PR at some point. Let's see what heisig and Bike say about this.
6:38:07
beach
I mean, it may sound like I understand the details, but my knowledge is quite fuzzy with respect to those details.
6:39:49
no-defun-allowed
What I am currently thinking is to store the unrestricted environment in the restricted environment. Then if we do not find a variable in a restricted environment, we consult the unrestricted environment and signal an error if the variable is only available in the unrestricted environment.
7:07:38
no-defun-allowed
Here we go, I produced the error message "The lexical variable X is not available at compile-time."
7:10:59
no-defun-allowed
Now bootstrapping produces an error and not a warning, but it is somehow nested: "ERROR while evaluating compile-time side effect: ERROR while evaluating compile-time side effect: The lexical variable #:ARGUMENTS-894912 is not available at compile-time."
7:12:37
no-defun-allowed
Or rather that the "error while evaluating compile-time side effect" format is nested.