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.
7:50:18
beach
The specific meaning I associate with the word is to make assumptions about the type of an object preceding the test for its type, in order to optimize an operation that is executed before the type of the object is known. And that kind of optimization violates the semantics of the language.
7:51:37
MichaelRaskin
What I have described does the same inference and call-replacement work, it just keeps a bit of humility to check once somewhere in the beginning, and default to a less efficient implementation of the error path.
7:52:24
MichaelRaskin
Ideally, one could propagate such checks further through calls and jump directly into the pre-checked part, but that sounds like even more work
7:56:10
beach
If the type is pre-checked, it doesn't correspond to the meaning that I associate with the word. Only optimizations that would violate the semantics of the language are included in that meaning, and such optimizations are not something I am interested in. It seems to me that what you describe is not a violation of the semantics, so then that is fine, but I would not use the word "backward" for such optimizations.
8:00:18
beach
If X is (say) a symbol, then the program should report an error in +. With a backward type inference, it could assume that X is a fixnum in in order to do the addition.
8:04:20
MichaelRaskin
OK, I would use both forward and backward notions more widely (just generally possible-output-type-based and presumed-input-type-based), but as you wish
8:05:17
MichaelRaskin
I just wanted to say that I understood that I had earlier missed a rather natural answer to your question > And what do you do with the last [presumed input type] type of information that doesn't violate the semantics of the language?
8:10:46
MichaelRaskin
(Indeed, we did not discuss that time what exactly counts as «backwards» for inference)