Commit 37d47afd authored by William G Hatch's avatar William G Hatch
Browse files

add comment about a type rule that is subtley broken

parent d7a43e2a
......@@ -324,6 +324,33 @@
(λ (n t) ;; int to float or float to int, but only in the same bitwidth
(begin
(printf (format "node: ~a, type: ~a" n t))
;; This type rule will break in funny
;; ways. This is probably something that I
;; need to document more clearly. But at
;; any rate, the problem is that multiple
;; of these cases can match (eg against
;; a non-concretized type variable),
;; and it will return a type from the
;; first case that matches, which may
;; influence generation. But then if the
;; type variable is unified (successfully,
;; because it was still an option) with
;; a type in a lower branch, that lower
;; branch will then succeed. So unification
;; elsewhere in the tree can change the
;; result of this rule. So you really want
;; to either:
;;
;; * Have different re-interpret node types
;;that fulfill different types so this
;;confusion doesn't happen
;;
;; * Concretize the type before doing
;;this match, and SAVE the result
;;of concretizing in a field of the
;;Reinterpret node. Then during type
;;checking, unify with the saved type each
;;time.
(cond
[(can-unify? t i32) (hash 'expr f32)]
[(can-unify? t f32) (hash 'expr i32)]
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment