freenode/#clasp - IRC Chatlog
Search
14:15:46
Bike
well, besides organization, karlosz set it up so that calls can use simpler conventions
14:16:07
Bike
for example, if you call a function bound with flet (so redefinability is not a concern, etc) it doesn't need a closure allocated
14:17:51
Bike
i haven't set up the type directed transformation stuff yet, unfortunately. my current plan is that instead of inlining global functions at ast level, they'll have a set of "transformers" attached, that rewrite the call in various ways
14:18:10
Bike
one of the transformers will just be inlining, so (a) it can use premade IR from the client instead of recompiling the AST, and (b) more policy control
14:19:31
beach
So the AST of the global function is still present in the caller AST, but could be discarded according to later decisions?
14:20:16
Bike
well, no, i'm planning on not including an inline AST at all. for the moment i'm holding off on that since i'm not doing sweeping changes in AST yet
14:21:36
Bike
the transformers are arbitrary functions, so for example a client could have some IR for CAR or whatever, eliminate checks in it based on type info, and then inline it
14:23:16
Bike
yeah. i think something pretty general is required for the specific kind of optimizations
14:23:32
Bike
but i haven't written any of this yet. might need some kind of toolkit to let clients write transformations cleanly
14:24:43
Bike
i know you're busy, but if you want to see what the BIR looks like I wrote a readme for it
14:36:10
beach
You did a great job on the explanations. I realize there is a lot more to write, of course. But what is written so far is very easy to understand.
15:39:00
Bike
right now i'm porting over the hir function copier, and when i tried it, a copied function being compiled caused translation errors
15:39:18
Bike
so i thought of some things i expect to be true of bir and wrote tests for them in the verifier
15:39:36
Bike
presto, better error, and i can run the verifier before and after transformations to isolate what caused the inconsistency
15:42:31
Bike
in the past i've effectively done that by graphing the ir and staring at it really hard, which isn't the most convenient workflow
16:18:55
karlosz
also, Bike, i don't know if you saw, but i added the "Unused lexical variable" warnings
16:20:58
Bike
like if we delete code later and references go with it, no warning. some warnings is a lot better than never warnings, though
16:21:38
karlosz
to only warn about variables that are clearly unused and written that way by the user
16:21:58
karlosz
we don't want to warn about variables that are unused because of compiler optimizations, that would be confusing and not helpful i think
16:23:03
karlosz
the thing that is missing is that the condition isn't a style warning as mandated in the spec because i was too lazy to add the condition and i don't know where that would go
16:23:45
karlosz
also warning about macroexpanded ignored variables is not good, but i figured that would require CST coordination/origin somehow
16:24:11
Bike
probably the client should be able to customize the actual presentation, but yeah i see. i'll merge that and look at little improvements then
16:24:35
karlosz
if you try a self build it really does catch many real instances of unused variables in the source code
16:34:09
Bike
so on the topic of expanding passes, when i was looking over the local call stuff i noted that you moved the actual interpolation into a post-find-local-calls function that's called by the local call finder
16:34:49
Bike
could we not just have an exported function for it and have the client call? i mean, i get that it works in terms of local calls now, but making it a package deal is kind of eh
16:35:00
Bike
which you mentioned in a comment, but why do CLOS stuff if we can just call or not call
16:52:18
beach
Now, if you fixed those package names, you could load Clasp code into a host Common Lisp as well. :)
16:52:21
Bike
hm, there are some in cleavir... but it's possible we're missing something like declaring specialized defmethod parameters as ignorable. i'll find out
16:58:02
karlosz
Bike: yeah i hear what you're saying about a package deal and i worry about that too
16:58:34
karlosz
it's just that that's the natural place to trigger it, hence it would be cool if a client could say "yes do convert lets right after detecting local calls"
16:59:33
karlosz
since im imagining we can potentially discover more local calls later, as a result of deleting a readvar or writevar or whatever, and that makes new code eligible for conversion, and... you get the idea
17:00:35
karlosz
Bike: also, keep in mind, some of the unused variable warnings are bogus because at the bir level, we currently don't understand if the variable is coming from source code or not
17:01:25
karlosz
and it sucks that there's nowhere to put ignore info into the lexical-ast, as far as i could find, so i kludged it and put it on lexical-bind
17:07:21
karlosz
i didn't check if any of the unused variable warnings in clasp were "real". are they?