freenode/#sicl - IRC Chatlog
Search
2:17:17
karlosz
beach: doing this read only optimization ended up being MUCH more involved than i had planned. i was able to do the optimization in segregate-lexicals pretty quickly until i ran into this function https://paste.gnome.org/pikoys0p9. as you can see, fact is an input to the enclose instruction, but is also the output, so when the read only optimization is made, the hir graph has an unresolved dependency
2:18:37
karlosz
so, me and Bike propose adding a new instruction, something like initialize-closure-instruction, that takes as input the output of enclose and all the other inputs that enclose used to take, and leaving enclose with no inputs
2:19:50
karlosz
the downside is that it is a side effecting instruction that is tied up with enclose pretty tightly, making hir transformations like inlining and remove-useless-instructions pretty hard to work with
2:19:59
Bike
i forgot that at least for clasp, the enclose would have to know the eventual size of the vector. i don't think sicl would though.
3:07:20
beach
karlosz: Yes, I see the problem and I think the new instruction is a good idea. Except I would call it SET-STATIC-ENVIRONMENT-INSTRUCTION or something like that.
3:08:41
beach
It is amusing that the static environment of a closure can contain the closure itself. I had never thought about it, but that must obviously be the case.
3:52:55
beach
karlosz: For mutually recursive functions introduced by LABELS, the occurrences of the new instruction must be after the last ENCLOSE-INSTRUCTION.
4:15:26
beach
When do you introduce the new instruction? Immediately in AST-to-HIR, or as a result of closure conversion?
4:31:05
karlosz
okay, this is actually a pretty big problem. if all the initializers must come after all the encloses, that means that none of the enclose instructions can be funcalled until that happens
5:11:03
karlosz
im seeing something weird. apparently this happens with not only enclose instructions but also catch-instructions
5:28:02
karlosz
my very naive first attempt at a solution for the insertion problem https://paste.gnome.org/pfbmhtec9
6:20:05
beach
So if E is an ENCLOSE-INSTRUCTION creating a closure C, and if C uses some shared read-only variable V, then the static-environment creation instruction must be inserted after the definition of V. So if there are several such variables, the static-environment creation instruction must be inserted after the last definition.
6:21:56
beach
And I think there must be a straight-line instruction sequence between the ENCLOSE-INSTRUCTION and all definitions of shared read-only variables.
6:25:35
beach
That might not be quite true. But, we only consider a variable read-only if it has a single defining instruction. And in that case, the straight-line instruction sequence must exist.
6:28:16
beach
Could there be a branch such that one path does not call C and only the other branch has a definition of V?
6:31:19
beach
Shared variables must have their origin in the source code. Temporaries can not be shared.
6:31:52
beach
And the only way to create a variable in source code is through some binding construct.
6:46:31
beach
... and of course, CATCH-INSTRUCTION is a binding construct for the CONTINUATION output.
7:40:07
beach
Different subject: currently, we have two generic functions EVAL and CST-EVAL, both defined so that their names are in the CLEAVER-ENV package.
7:42:59
beach
Instead of (form environment environment) and (cst environment environment system), I will try to make it (client form environment) and (client cst environment) respectively.
7:53:34
beach
It is a parameter used for dispatch. CST-to-AST already has a client parameter, and for things like converting MACROLET (which needs for the macro function to be evaluated), it would call EVAL or CST-EVAL, passing that client.
7:54:09
beach
So client code can specialize the behavior of EVAL and CST-EVAL according the structure of its environment, and how it wants evaluation to happen.
7:54:44
beach
Some clients might want to call an interpreter. Some others, like SICL, will evaluate by converting to AST, to HIR, to Common Lisp, and then execute the result.
8:23:27
Shinmera
How bad of an idea is it to add methods to MAKE-INSTANCE that will potentially return a cached instance of an object instead of creating a new one
8:25:39
beach
I don't think that's a problem as long as your class is documented to have that behavior.
8:35:11
jackdaniel
in one project I have a macro define-class which defines class <class>, function <class> (like make-instance) and a variable <class> assigned to find-class on it
8:37:53
jackdaniel
it is quite intuitive, and given I use in this project consistent naming (class names are always in <>) it is also "easy for the eyes"
8:50:42
beach
In fact, I don't understand why the current PARSE-MACRO is part of the CST system, since it doesn't use CSTs in any way. It must have been the intention all along to have it work on CSTs.
8:55:34
shka__
it would be logical to simply put all of those in CST package instead of adding prefixes
8:56:34
beach
I don't think CST-EVAL belongs in the CST package. Maybe CST-PARSE-MACRO doesn't either. I need to think about that.
9:11:35
beach
*sigh*, I can't tackle that particular issue right now. I am hoping it is not a great problem because it will just mean that the MACRO-FUNCTION resulting from a macro definition will not have source information. So any expression in an expended form that originates in the macro function itself will not have source information.
9:19:33
beach
Though, looking at the lambda-list destructuring code in Concrete-Syntax-Tree makes me think it would not be too hard to write a CST version of PARSE-MACRO.
10:05:29
makomo
and <foo> here is a metavariable, or did you literally include the characters "<" and ">" within your names (you said "class names are always in <>" so it confused me)?