freenode/#sicl - IRC Chatlog
Search
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)?
10:10:13
makomo
yeah, because the characters "<" and ">" are usually used to denote metavariables. i.e. "<foo>" usually doesn't mean "literally the character sequence '<foo>'" but "an instance of something that follows the rule 'foo'" (sometimes even coupled with "all occurences of that <foo> must be identical")
10:16:56
makomo
true. i read some parts of it (fare's blogpost on it) but haven't looked at it in detail or used it