freenode/#sicl - IRC Chatlog
Search
12:18:48
shka_
because of a bad prior decission current protocol has this messy concept of multistage aggregation
12:19:37
heisig
I'm genuinely curious about the performance you can get. Also, I think it is an interesting challenge to design the right protocol for working with these closures.
12:24:11
shka_
range can act as a closure factory, and all i reall need is one function to push stuff down in aggregation
14:20:41
beach
Bike: I did what splittist calls a "brain dump" this morning. It is probably stuff that is hard to digest by most #sicl participants, but if you could have a quick look (at your leisure of course) I would appreciate it. It should be in the logs.
14:22:52
Bike
i thought you were going to have some kind of local unwind instruction, but maybe i misunderstood
14:24:54
beach
I was going to, but it seems it is not necessary, and it doesn't solve the problem anyway.
14:27:03
beach
I mean, sure, I could stick such an instruction whenever there is a change in the dynamic environment, but I wouldn't know what to do with it. And if I stick it in as a result only of a RETURN-FROM or GO, then that won't solve the problem, because I may have UNWIND thunks to execute in other cases as well.
14:32:59
beach
A different solution would be to implement UNWIND-PROTECT always as a function call. That would force an UNWIND-INSTRUCTION whenever the cleanup forms need to be executed. But I still need to pop the environment for local changes like when a LET binding of a special variable ends normally.
14:35:10
Bike
so if you trun a local exit through an unwind protect into a "grab thunk, funcall it" thing, is there a similar sequence for a special variable unbinding?
14:36:39
beach
No, and that's the thing. All I have is two consecutive instructions to be executed in different dynamic environments.
14:39:34
beach
Again, all I have as output from AST-to-HIR is two consecutive instructions in different environments.
14:44:02
beach
So, if memory serves (HAHAHAHA!!) I meant to handle it as a special operator that generates an instruction UNWIND-PROTECT-INSTRUCTION.
14:45:56
Bike
i'll have to think about how special variable un/binding can work in clasp right now. i don't think the representation here is very amenable to what clasp is doing.
14:46:57
beach
It should work. If I introduce a special UNBIND-INSTRUCTION, then that could be turned into the actions you need in order to unbind.
14:49:00
beach
Right now I am thinking of it as being introduced in this post-AST-to-HIR transformation when there is an instruction with a successor in a different environment, and the difference is a bind-instruction.
14:50:40
beach
To generate it directly, the compilation context would have to contain a representation of the dynamic-environment stack.
14:52:30
beach
That could be fixed of course, which might in fact be the best solution so that the information does not have to be re-derived.
14:58:10
beach
I might make it a transformation for now, and put off modifying AST-to-HIR until later on.
15:00:35
beach
In order to plan for such a change to AST-to-HIR for later, I would need to be convinced that I am not doing anything that would be impossible to process for certain clients.
15:01:39
beach
But the more I think about that, that appears to be the good solution: Change the compilation context so that it contains a stack with the symbolic representation of the dynamic environment.
15:06:00
beach
I know I have only a small number of cases left to handle before I can generate native code. But it seems that every new case I tackle requires a significant change or addition before it works to my satisfaction.
15:09:36
beach
So, let's think about UNWIND-PROTECT. When a programmer uses that, it's that there is a possibility that there is a non-local transfer through it. So we do need to create a thunk and stick it in the dynamic environment. There could be a possible optimization when the protected forms terminate normally, but it may not be worth the trouble.
15:12:51
beach
It seems reasonable to compile it as an ENCLOSE of a nested function, an UNWIND-PROTECT-INSTRUCTION that takes the thunk as the input and the instructions of the protected form as its successor.
15:14:21
beach
The instruction adds an UNWIND-PROTECT entry that contains the thunk to the dynamic environment.
15:15:37
beach
The local control transfer from the protected form to the successor of the UNWIND-PROTECT form will be one where the dynamic environment is different.
15:16:08
beach
So we detect statically that there is an UNWIND-PROTECT entry on the dynamic environment, find the thunk and funcall it.
15:16:37
beach
I mean, we introduce and instruction in that control arc to find the thunk, and we introduce another instruction to funcall it.
15:17:31
beach
But that could be bundled up into a single instruction, which might be better for clients that handle UNWIND-PROTECT as a function call.
15:21:21
beach
So, in summary, I think all these changes to the dynamic environment should be explicit in HIR code, so that clients that have machinery for handling them locally can do so, while still allowing for clients who wish to turn them into function calls to do so.
15:24:03
beach
Great! I will likely try it out. Nobody but SICL is using Cleavir2 yet anyway, so there would be time for modifications if it turns out I do something that Clasp can't handle.
15:31:06
beach
I alternate between thinking that Clasp grabbed Cleavir a few years too early, because I hadn't had time to iron out many of these issues, and thinking that many of those issues I might not have figured out, or they might have taken me a very long time, if it weren't for all the design work that Bike has contributed.