freenode/#sicl - IRC Chatlog
Search
19:53:12
karlosz
i wouldn't flush it because you might still want (lambda (x) (the fixnum x) y) to do a runtime check
19:59:43
Bike
it's involved in a snag i hit while removing rtypes. i guess to figure out if a thei needs actual multiple values i need to look at the type?
20:00:52
Bike
there's only one bit of code in clasp's extended sequences library (why? i don't know) that hits this
20:01:09
karlosz
if we ironed out our use of values types vs non values types everywhere it should be possible to just find out if its unknown-values from looking at the types of the outputs and stuff
20:07:12
Bike
i thought sbcl only gave up checking on things like values &rest types, which nobody uses anyway
20:07:43
karlosz
sbcl can do more types of conflicting i believe, and i think there are some oddities with the representation i ended up choosing for thei checking
20:08:07
karlosz
Bike: yeah, the values &rest checking is too hairy to check, and we have the same problem, except instead of saying its too hairy i think we do the wrong thing?
20:10:28
Bike
how does it work now? like, there's the type check function, and it's mv-called? and then returns the values, or no?
20:17:07
Bike
i thought the translation layer in clasp was the only thing that actually needed rtypes
20:27:07
karlosz
i was thinking the type check generation should just be thrown into mir altogether?
20:28:11
Bike
thei should be an identity possibly with side effects. so it needs multiple values if its output does. but there are some other optimizations possible, like if we infer the input is one value
20:34:40
Bike
how about - if thei doesn't have a type check function, it has the same rtype (or rather needs values coerced in the same way) as whatever it outputs to. if it does, we could always have it accept multiple values, and then pick off other cases based on inference
20:35:49
Bike
i think i'll just do that since if there's a type check it doesn't need to be enormously fast anyway, so extra values thrown around are whatever
20:37:03
Bike
then i can have generate-type-check always do the mv call rather than checking the rtype
20:39:50
Bike
karlosz: although - what's the deal with a tcfunction of :external? i don't understand your comment.
20:53:42
Bike
hang on. actually. if we do this then the optimizations we want to do are the same as we want for ANY mv call, i think
20:54:03
Bike
like if we have (mvc type-check-function form), and derive that form returns exactly one value, we make it into (funcall type-check-function form)
20:56:11
Bike
and similar for the return values, since ideally we would have local calls not forcing everything into unknown values returns like it does now
20:58:29
karlosz
Bike: :external is kinda a hack for compile time checking arguments of inlined function. the commit might explain it better
20:59:14
karlosz
yeah in sbcl all the decisions for whether to do unknown values or known values stuff is driven off of the ctypes of lvars
21:35:03
Bike
i guess this is how we can do type check functions correctly and performantly. first, we write the functions to return all values, by doing something stupid like (multiple-value-call #'values ,@required (values-list ignore)). then we derive the type of ignore to be NIL (if we figure out the number of values), which lets that be reduced to (multiple-value-call #'values ,@required), which is just (values
21:56:54
Bike
it might be necessary to rethink values-collect a bit. right now it's a little magical in having all its inputs but one be a specific kind of instruction
21:57:31
Bike
in reality we might have some heterogeneity in values counts, having various numbers of known values forms and unknown values forms