freenode/#sicl - IRC Chatlog
Search
11:36:35
beach
I have a dilemma. Let's say for the moment that I don't separate the ENCLOSE-INSTRUCTION from the instruction that sets the static environment. So I can't do the optimization that karlosz implemented, which would be fine for the first executable that I am now working on. I want to turn the ENCLOSE-INSTRUCTION into a FUNCALL-INSTRUCTION calling (say) ENCLOSE.
11:36:36
beach
So the variable holding the ENCLOSE instruction is typically shared. Therefore, I want to turn the ENCLOSE-INSTRUCTION into a FUNCALL-INSTRUCTION before closure conversion. But closure conversion needs the ENCLOSE-INSTRUCTION for its operation, so I need to have it present during closure conversion.
11:41:49
beach
I guess I could insert an FDEFINITION-INSTRUCTION (for ENCLOSE) before every ENCLOSE-INSTRUCTION and a USE-INSTRUCTION after the ENCLOSE-INSTRUCTION, using the variable that is the output of the FDEFINITION-INSTRUCTION.
11:42:31
beach
I then just have to find the USE-INSTRUCTIONs later when I convert the ENCLOSE-INSTRUCTIONs to FUNCALL-INSTRUCTIONs.
12:01:28
beach
GAH! CREATE-CELL-INSTRUCTIONs are even worse. They need to be turned into FUNCALL-INSTRUCTIONs (calling CONS). But CREATE-CELL-INSTRUCTIONs don't exist until after closure conversion, so I can't do the trick that I just invented for the ENCLOSE-INSTRUCTION.
12:02:50
beach
A simple solution to these problems would of course to have every static environment always contain a location holding these functions, but that does not seem very elegant.
12:03:35
beach
I suppose I could do that for the initial version, though. It would simplify many things.
12:14:01
beach
It really helps to regularly remind myself that this is the initial version I am working on.
12:16:19
beach
So now I just need to decide what the static environment always contains, and in which order (the static environment is a simple vector).
12:45:55
scymtym
beach: i would like to "flip" the way backquote contexts work in eclector: allow backquote (and unquote) by default and disable one or both in certain contexts. https://github.com/robert-strandh/Eclector/issues/57 prompted this but i realized that an approach based on explicit disabling for certain contexts allows better error messages: https://techfak.de/~jmoringe/style-check-4.png . do you see any problems with this?
12:52:47
beach
Not really, no. Other than the maintenance problem I think I documented in a comment about the reason for doing it this way.
12:56:41
scymtym
it probably comes down to whether backquote should be allowed in custom reader macros or not
12:58:03
scymtym
the iterate library defines a reader macro that reads #L(list !2 !3 !5) as a LAMBDA expression
13:00:31
scymtym
ok, thanks. i will experiment a bit more, but i think supporting cases like this is probably better overall
13:02:53
beach
Either way, it has to be documented what the creator of reader macros must do to get the case that is not the default.
13:02:54
scymtym
yes, i could flip the default and expose the mechanism for disallowing backquote and/or unquote
13:04:32
scymtym
ideally they would provide a context name (a symbol) and define a method on CONTEXT-NAME to get a localizable error report, but that may be too much to ask
16:50:46
karlosz
beach: yeah, the read only optimization interacting with labels is the main reason i decided to introduce the new instruction where it is introduced now