freenode/#clasp - IRC Chatlog
Search
13:24:43
Colleen
Bike: karlosz said 7 hours, 57 minutes ago: what happened to type checks? i can't seem to get any to spawn anymore
13:33:11
Bike
i'm looking at phasing out &va-rest and one important thing we use it for is C++ functions
13:33:28
Bike
which would prrrrrobably still need lisp compiler support cos of the direct calls stuff? maybe?
13:34:23
Bike
karlosz: (locally (declare (optimize safety)) (the cons 4)) is still a type error for me
13:43:01
Bike
other than that, we use va-rest... not that much, and mostly in contexts where it could be changed to &rest immediately (e.g. only used for passing to APPLY)
14:26:10
Bike
i forgot i already hacked bind-va-list to actually do apply. doesn't seem to have noticeably impacted speed
15:21:01
drmeister
Were you going to open space to store a couple of CONS cells in the stack frame of functions that take &rest xxx and xxx doesn't escape and copy the arguments into them?
15:21:58
drmeister
I'd really like to phase out &va-rest everywhere. That's one way I see of dealing with it in C++
16:59:02
Bike
plenty of C++-for-lisp functions that use &va-rest but i don't know if that requires compiler support or what.
18:45:56
karlosz
constant folding typeqs with constant arguments applies 118042 times during self build when meta-evaluating
18:46:46
karlosz
it seems like there's lots of potential for constant folding stuff, so having the database will be good since im sure there are a bunch of known calls to things we can fold out
18:47:17
karlosz
i need to supplant the current typeq folding with a more type based approach rather than just testing for a constant reference
18:48:23
karlosz
should be a lot more efficient too than just introducing typews on all constants like we did with hir
19:11:18
Bike
mmhm. sounds good. a while back i changed ctypes a little to move it towards more invovled type derivations
19:19:22
karlosz
a cast instruction means we'll need to look through the cast to get the real value which is annoying
19:20:07
karlosz
and just having an asserted type slot means we'll need to insert cast instructions as bmir or something which is fine but might cause its own problems
19:20:34
Bike
are casts directly related? i mean i'd think of a "cast" as an actual operation, like unboxing
19:20:39
karlosz
of course both of these strategies don't really have a good way of representing the actual type check code in BIR
19:20:50
Bike
and in that context they ought to be inserted later rather than present at type inference time
19:21:20
karlosz
by "cast" i just mean a computation which takes a linear-datum of type X and is a linear datum of type Y
19:23:21
karlosz
now that we have linear-datum's our evaluation on what the best representation of this might change
19:24:00
karlosz
it would be nice if we didn't have to introduce lexical variables and could work only on the linear-datum's (i.e. expression values)
19:28:14
karlosz
this has the benefit that (the <ty1> (the <ty2> <e>)) gives the right asserted type on <e> immediately during conversion
19:29:50
karlosz
right, so the only thing here is we need to splice in type checking code like checkgen.lisp does in Python
19:30:43
karlosz
i think its doable if we just define a good interface for clients to specialize how they want to do it
19:33:23
Bike
https://github.com/clasp-developers/clasp/blob/30da903d56dec261f4ae591d1fc2b2f9b66b81b0/src/lisp/kernel/cleavir/hir-to-mir.lisp#L185-L239 i was so glad to delete all this