freenode/#sicl - IRC Chatlog
Search
13:23:27
beach
heisig: Did you see that I managed to program ASDF and it was quite simple. Well, I haven't finished the programming quite yet, but I will soon integrate it into the bootstrapping procedure.
14:51:01
beach
I must say I am very pleases with these BleuJour OCTO computers, especially since they don't crash, but also that they are so small they can be mounted on the back of a screen. And I much prefer Mint over Ubuntu. Cinnamon on Mint is much closer to the way I want my desktop than Cinnamon on Ubuntu, and certainly than the Ubuntu default desktop.
15:37:38
beach
Heh, thanks. It was just a matter of defining a new operation, and defining that it is its own "sideways" operation. That will make the ASDF plan correct.
15:38:32
beach
And since I need for the perform to load stuff into a particular first-class global environment, I will make the environment a slot in the new operation.
15:39:06
beach
In fact, I will use the CLIENT object in the bootstrapping procedure as the ASDF operation object.
16:12:58
beach
It was just a matter of defining a new operation, and defining that it is its own "sideways" operation. That will make the ASDF plan correct.
16:14:08
beach
I guess I need two methods. One default method that does nothing. And one on lisp file that does the loading.
16:14:44
beach
I also had to kludge a bit to get around the fact that ASDF requires me to use MAKE-OPERATION rather than MAKE-INSTANCE.
16:22:55
beach
I see. Well, it also doesn't take any initargs, but I made a subclass of OPERATION that requires initargs. So I called MAKE-OPERATION and then REINITIALIZE-INSTANCE.
16:32:06
beach
The second time I invoke ASDF:OPERATE, it does nothing. So somehow it remembers that it already did the operation and skips doing it again.
16:44:57
beach
jackdaniel: The main idea I had was to just do a Kildall-style iteration with some finite type lattice.
16:47:29
beach
Well, Kildall's algorithm is just iterating over the instruction graph until a fixpoint is reached. The details can vary greatly.
16:49:16
beach
For type inference, you need to split the types when you see an instruction that checks the type of a variable. Then for a join, you need to do the OR. But the trick is to have a sufficiently detailed lattice that it is useful, while avoiding performance problems.
16:49:55
beach
My (admittedly small) family just announced that dinner is served. I'll be back tomorrow.
16:50:52
Bike
so for cleavir2 karlosz's ideas are more like how sbcl's works... which is still a kildall dataflow thing somewhat, but with another flow-insensitive process as well
16:51:14
Bike
https://github.com/s-expressionists/Cleavir/wiki/How-to-represent-and-do-type-derivations-in-BIR this one i think
16:53:30
Bike
if you have something like (+ x (+ y z)), you don't really need to know the flow order, just that the output of one addition is the input to the other. you can reason about stuff like that without worrying about the flow
16:53:49
Bike
and then use the flow for the "in this branch of the (if (consp x) ...) x is a cons" kind of stuff
17:13:31
jackdaniel
does it mean, that cleavir2 doesn't have (yet) the type inferencer implemented but there are plans for it? I must have remembered it wrong earlier then
17:14:23
Bike
it's partly implemented, but i need to fix up some infrastructure before it can get really detailed information about things like interval arithmetic
18:31:07
fiddlerwoaroof
Is there an existing mechanism to run Cleavir's optimization passes on a bit of code and then produce lisp as the output?