| 26 Jul 2024 |
 enebo | which would be special logic | 15:29:59 |
 headius | maybe dummy scope | 15:30:02 |
| headius | but this also deopts vars to use dynscope even though it's totally unnecessary | 15:30:14 |
| enebo | it is just we have some generic logic and that logic could go oh dummy scope don't look at current one | 15:30:24 |
| headius | so basically we just fully deopt the block only to be able to walk up to the return scope | 15:30:29 |
| headius | I think I knew this was how it works but I had forgotten... this could be deopting tons of scope | 15:30:51 |
| enebo | but I don't really know how we do that unless we assign scope as a temp or something in this case | 15:30:56 |
| enebo | right not I think it is just looking a getCurrentScope | 15:31:06 |
| headius | it makes this language impl dreadfully slow | 15:31:06 |
| headius | right that's how it gets the scopes to walk | 15:31:24 |
| enebo | So I think if we give scope another temp var and not %scope we can initially give it dummy but we would then always need to indirect through at temp which would be copy(the_temp, %scope) or something | 15:32:33 |
| enebo | And I am not looking at code as I say this but I believe we are looking at runtime state directly | 15:32:56 |
| headius | we have logic to reuse parent scope for for | 15:33:31 |
| enebo | anyways the way to fix this is that we look at current scope and it is the method scope but we are still in the block | 15:33:37 |
| headius | it would be similar here | 15:33:41 |
| enebo | so we need to know in that case we need to unwind more | 15:33:48 |
| headius | right | 15:33:56 |
| headius | I know how to make all this stuff work but it needs time | 15:34:25 |
| enebo | yeah so indirecting from just checking scope to a variable where initial is set to dummy/anything really probably fixes this | 15:34:29 |
| enebo | but this also means we have to cope with nesting | 15:34:42 |
| enebo | since n closures would all have the same runtime scope | 15:34:54 |
| enebo | so there is more complexity | 15:35:01 |
| enebo | heh we need another marker | 15:35:29 |
| enebo | Goign to help with lunch bbiab | 15:35:41 |
| headius | I have other things I want to do, like always passing the block's dynscope in as an argument rather than going to context for it | 15:36:32 |
| headius | trying to get it closer to something escape analysis can eliminate rather than pinning it on heap | 15:36:46 |
| headius | and in that case we could pass in a dummy scope as long as it still knew to use normal local vars | 15:37:01 |
| headius | sometimes I feel like IR compiler is more complex than it is worth to make it do the right thing | 15:37:26 |
| headius | but I know I need to understand it better | 15:39:00 |
| enebo | yeah I have been reasonably happy in how I can reason with it but I also feel it can be complicated. Sometimes I think it is a function of not having written it originally. Also that it is a design for a compiler and not a runtime. I would also probably redo it with a stack-based design | 16:16:50 |
