libera/#sicl - IRC Chatlog
Search
7:36:15
MichaelRaskin
beach: I understood that I missed one case where optimiser _might_ be interested in type inference backwards (if there is no error, this input value to a function must have a specific type). But surely not a priority optimisation.
7:37:17
beach
I can see how it would be good for optimization, but I don't see how you can make it conform to the semantics of Common Lisp.
7:37:17
MichaelRaskin
If I feed some variable foo to functions bar and then baz, it would be nice to have a call to baz pre-optimised for the case bar did not signal a type-error, with some inefficient fallback for USE-VALUE restart.
7:40:43
beach
When I see "backward", I think about a situation like Baker describes, and that statically typed languages take advantage of, namely if a value is used in a context where it has to be of a certain type, then it can be assumed that the variable is of that type prior to that context.
7:43:45
MichaelRaskin
With the approach of putting an «if» switching between two identical copies of a function, you can propagate the type restrictions backwards and switch between the no-error case which is hopefully the common case and can be optimised better, and type-error case where you can shrug and not optimise much
7:44:47
beach
Yes, but again, that's not the meaning I put into the word "backward" in this context.
7:46:23
MichaelRaskin
I would say it is very close. You do almost exactly the same work on the data flow graph, and in the end just put a second copy of the function instead of signalling an error immediately.