libera/#sicl - IRC Chatlog
Search
3:08:47
beach
zephyr: I don't remember whether that argument is in the paper, but I do bring it up when I talk about it.
8:40:29
beach
Maybe the AST evaluator and the HIR evaluator should be part of the bootstrapping code.
8:41:36
beach
Currently, the HIR evaluator creates instances of its own function class when it encloses some code. It should really create an instance of the same object that is used during bootstrapping.
8:49:30
beach
I am also thinking more about the different roles of functions in E5. Currently, the HIR evaluator is used when a function is created in E5, but the HIR code is also transformed to MIR -> LIR -> Cluster -> binary.
8:49:54
beach
The result of calling the HIR evaluator is useful only when the function is going to be called as part of the bootstrapping procedure.
8:50:20
beach
The main purpose of E5 (right now at least) is to contain binary code to store in the executable file.
8:52:12
beach
Of course, the top-level function of a compilation unit loaded into E5 must always run through the HIR evaluator so that the side effects of top-level source forms are executed.
8:53:31
beach
But often, the only side effect is to create some functions and store them in the environment. Those functions are never executed as part of the bootstrapping procedure, so there is no need for the HIR evaluator to turn them into host code.
8:58:25
beach
Conversely, the top-level function of a compilation unit loaded into E5 is not needed in the executable, so there is no point in generating MIR, LIR etc. Once it is executed by the HIR interpreter, it has served its purpose.
9:01:14
beach
Not that all this matters in terms of performance, but I am intrigued by these roles, and I don't fully understand the consequences of the role distinction.
9:04:35
beach
Take the common case where a file contains a bunch of top-level DEFUN forms. Each function needs to be turned into HIR, MIR, LIR etc. of course, but the code for storing them in the environment does not have to be executed by the HIR evaluator. It could be done by the AST evaluator for instance.
9:05:39
beach
And the objects created to represent those functions each consists of a header and a rack.
9:06:37
beach
The rack is what contains the information needed in the executable, whereas if the function is to be executed later during bootstrapping, the code is then in the header, since the header is a host funcallable-standard-object.
9:07:31
beach
So we could theoretically use different code for the two, like a host function for execution.
9:08:54
beach
Again, I don't think it matters in terms of bootstrapping performance, but it may matter in how the bootstrapping code is ordered.
9:15:46
beach
Consider the difference between two different compilation units (i.e. files), say A and B. A contains (defun f () ...) as a top-level form, and B contains (let ((x ...)) (defun g () ...)) as a top-level form.
9:17:45
beach
So in A, that code can be executed by the AST evaluator rather than the HIR evaluator.
9:18:35
beach
But in B, it has to be executed by the HIR evaluator, because it is only after the code is turned into HIR that we know that we have a closure.