freenode/#sicl - IRC Chatlog
Search
14:15:29
Bike
compile time evaluation - since the compiler is slow, if we use an interpreter instead for simple stuff compilation is faster
14:16:07
Bike
oh, but it's not complete though. because of that use case, for some of t he more complicated stuff we just give up and use the compiler
14:18:44
Bike
i don't remember what it doesn't handle... it does blocks, tagbody, closures, multiple value stuff...
14:19:26
Bike
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cleavir/ast-interpreter.lisp here it is. hopefully it could be a starting point if nothing else. it's pretty simplistic
14:23:05
Bike
geez, why did i write my own lambda list parser... clasp has to have like five of those by now...
14:23:55
Bike
environments are hash tables... if you use this for substantial code you may hti performance problems
14:25:22
beach
Well, another idea would be to turn the AST into host code for compilation. I abandoned it in the HIR compiler, because the code became huge. But the result of turning ASTs into host code ought to be significantly smaller.
16:31:57
froggey
alright, after pulling the Cluster changes it gets through (boot) without any problems
17:04:20
beach
Have you also tried to understand how the boot procedure works, and if so, do you have opinions about it?
17:11:07
froggey
only very superficially. it's surprisingly fine grained, with each phase importing exactly what it needs from the host
17:12:28
beach
Yes, it didn't used to be that way. I used to import pretty much everything, but it became harder to find certain bugs then.
17:20:14
froggey
the HIR interpreted turns backtraces into a soup of INTERPRET-HIR calls, which makes them difficult to understand. that's probably more a problem with CL debuggers not being extensible enough
17:25:14
beach
I hesitate to add specific tools to the bootstrapping environments, because it's a lot of work, but if I can find a way of writing those tools in a "natural" way and reuse them in the bootstrapping environments, that would be good. A backtrace would be such a thing. I did write some customization code for Clouseau so that I can inspect the objects in the bootstrapping environments.
17:36:33
froggey
it did get me thinking about how backtraces could be made extensible. right now there's code in mezzano's debugger to identify generic function discriminator functions in the trace and replace them with the generic function itself
17:37:36
beach
OK, see you. My (admittedly small) family is going to call me to dinner very soon as well.
17:39:09
beach
My tentative plan is to show source locations in the backtrace. That way, I shouldn't have to care much about the objects. Or at least that is what I am hoping.
19:08:25
Bike
gonna experiment a little with maintaining extra information in function ASTs and enter instructions. a name and docstring to start with, but maybe bound declarations for the variables too