libera/#sicl - IRC Chatlog

12:19:35 beach Let me see whether I remember this correctly...

12:19:42 beach Before the introduction of the CATCH-INSTRUCTION, I used a much simpler scheme with an UNWIND-INSTRUCTION that would be generated from a GO or a RETURN-FROM, and it would have as a target the instruction to follow in the control flow, but typically in a different function.

12:19:48 beach But this simpler scheme made instruction ownership hard to compute, and we need instruction ownership for things like closure conversion, and perhaps other things as well.

12:19:56 beach Now, if I manage to do closure conversion at the AST level, instructions would be generated separately for each function, so instruction ownership would be clear from the start.

12:20:04 beach Does that mean that the simpler scheme will again work? If so, a BLOCK or a TAGBODY that have a corresponding non-local RETURN-FROM or GO would just have an instruction that does the equivalent of (let ((dynamic-environment (augment-dynamic environment ... dynamic-environment))) ...).

12:20:35 beach And I can re-introduce the UNWIND instruction.

14:48:44 bike karlosz has pretty much convinced me that it's more convenient for unwinds to appear as normal successor control flow, but i haven't gotten around to fixing things up for it

14:49:44 beach You mean sort of the way it used to be?

14:49:49 bike yeah.

14:49:54 beach I see.

14:50:28 bike bir no longer computes instruction ownership like hir used to, so that shouldn't be a problem, and i think that was basically the only problem

14:50:49 beach Yes, I see. Good to know.

14:51:10 bike unrelatedly... i'm thinking i should fix up ctype to have extrinsic/intrinsic systems, or at least to have a specializable client parameter. then it would be possible to load ctype and check out different type relationships in different implementation systems and bla bla bla. would having a client parameter disrupt sicl's use of ctype terribly?

14:51:38 beach Nah, I'll be fine. Good idea!