freenode/#sicl - IRC Chatlog
Search
3:56:30
beach
jcowan: You could treat them all in a similar way, but then RETURN-FROM and GO would be more expensive than they currently are. Since they are static constructs, the compiler takes advantage of that fact to generate more efficient code.
14:11:24
beach
For example, it might be good to define one or more environment-augmentation functions, rather than CONS and MAKE-...-ENTRY.
14:12:11
Bike
oh, well, yes. I was focused on the Cleavir part. those functions could still be more on the backend level, I think.
14:12:19
beach
Also, I need to think about the idea of keeping references to parent ASTs and to the function AST. Maybe a special type of variable holding the environment would be better.
14:13:05
Bike
With the references I think the thing is this does need to be available in HIR somehow or another, because it comes up in inlining.
14:13:59
beach
If the environment references turn into lexical variables (maybe a special type of such variables) then I think that would fix the problem.
14:16:33
Bike
so function-ast refers to a special lexical-ast, block-ast and etc. have one as input and one as output?
14:16:49
Bike
I was kind of going off analogy with closures, since the closure variable doesn't exist at ast level and all. but it's a different situation.
14:17:08
beach
In the SICL x86 backend chapter, I wrote that the time stamp is kept in the static environment of a function. Your suggestion makes me think that the dynamic environment should be treated like any other local variable, subject to capture, etc.
14:18:16
Bike
I'm not sure what would capture a dynamic environment - that would be treating it more like a lexical environment
14:19:36
beach
So, it can't be all on the call stack, because the stack can be popped and pushed even though some closure might contain a RETURN-FROM or a GO.
14:20:28
Bike
In the static environment, you said? Like the closed over environment? I think I missed that bit.
14:20:38
beach
But that's basically just another way of saying that the dynamic environment can be captured.
14:21:22
beach
So, essentially, the dynamic environment is captured, but what is captured can be rendered useless when the block/tagbody exists normally.
14:23:17
beach
But there could be a (f (lambda () (return-from ...))) inside the BLOCK and we might not know what F is doing with the closure.
14:25:06
beach
So, semantically speaking, the dynamic environment can not be allocated on the stack, because then there is no way of checking whether the exit point is still valid when a GO or a RETURN-FROM is encountered.
14:26:04
beach
By making the entire thing into a lexical variable that may or may not have dynamic extent in various situations, we handle the problem.
14:27:26
beach
Then, the implementation can choose whether to be strict about checking the validity of exit points, or not.
14:28:08
Bike
I think that if dynamic environments were written out like in the examples in the text, like just regular nested LETs, and every call explicitly referred to one that had the environment in scope, we actually wouldn't need to invalidate exit points upon normal exit from a block scope- invalidated exit points would just not be present in other calls
14:29:30
beach
But my example above with (lambda () (return-from ...)) is a situation where a strict implementation would need to invalidate.
14:30:24
Bike
Like (defun f (c) (setf *global* c)), and then (block nil (f (lambda () (return ...)))) - that's what you mean, right?
14:31:13
Bike
So in that case, if *global* was called after the block returns, the closure would refer to a block that would not be present in the dynamic environment of that call. So no special invalidation is required.
14:32:25
Bike
"Whenever transfer of control to an exit point is initiated, the exit point is rst searched for. If no valid exit point can be found, an error is signaled." this part.
14:34:24
beach
In the lexical environment of the function that does the transfer, so it is subject to capture and is not necessarily dynamic extent.
14:35:04
Bike
Yes, but it's not the dynamic environment, it's a saved tag. It's the lexical variable I already added the last time I decided to change everything
14:35:33
Bike
So like, if that is the same as the dynamic environment entry, that _entry_ isn't dynamic-extent, no.
14:36:41
beach
The dynamic environment could just as well be a chain of entries held in local variables.
14:36:42
Bike
Right. Yes. Parts of the entry are certainly not dynamic-extent and have to be saved in closures- but the dynamic environment itself, the cons, I think that still is stack-allocatable.