Go to the source code of this file.
Typedefs | |
| typedef sherpa::EnumSet< TI_FlagValues > | TI_Flags |
| typedef sherpa::EnumSet< UnifyFlagValues > | UnifyFlags |
Enumerations | |
| enum | TI_FlagValues { TI_NO_FLAGS = 0x000u, TI_TYP_EXP = 0x001u, TI_TYP_APP = 0x002u, TI_TCC_SUB = 0x004u, TI_TYP_DEFN = 0x008u, TI_DEF_DECL_NO_MATCH = 0x010u, TI_NO_PRELUDE = 0x020u, TI_NO_MORE_TC = 0x040u, TI_ALL_INSTS_OK = 0x100u, TI_METHOD_OK = 0x200u, TI_USING_FQNS = 0x400u } |
| Flags used by Type-inference engine. More... | |
| enum | UnifyFlagValues { UFLG_NO_FLAGS = 0x00, UFLG_UNIFY_STRICT = 0x01u, UFLG_UNIFY_STRICT_TVAR = 0x02u, UFLG_UN_IGN_RIGIDITY = 0x04u } |
| Flags that control the unifier. More... | |
| typedef sherpa::EnumSet<TI_FlagValues> TI_Flags |
Definition at line 96 of file TypeInfer.hxx.
| typedef sherpa::EnumSet<UnifyFlagValues> UnifyFlags |
Definition at line 129 of file TypeInfer.hxx.
| enum TI_FlagValues |
Flags used by Type-inference engine.
They are used for communication/processing within the different Type inference procedures, and for driving the inference engine under certain special conditions.
| TI_NO_FLAGS | |
| TI_TYP_EXP | Inference engine is now within a type AST (ex: (fn int -> bool)) |
| TI_TYP_APP | Inference engine is within a type AST that is a type application (ex: (pair int bool) |
| TI_TCC_SUB | Inference engine is processing a subsumed type class (ex: Since Ord is a sub-class of Eq, the presence of Ord constraint subsumes the presence of another Eq Constraint) |
| TI_TYP_DEFN | Processing a Type definition (ex: defstruct and defunion) |
| TI_DEF_DECL_NO_MATCH |
No longer need to check Declaration/Definition matching.
The following flags are used to drive the inference engine under specific modes/conditions. |
| TI_NO_PRELUDE | Don't import prelude. |
| TI_NO_MORE_TC | No more type classes: The inference system will not add default constraints (ex: IntLit/FloatLit constraints on Integer/Float literals). This mode is used beyond the polyinstantiation pass. |
| TI_ALL_INSTS_OK | No longer need to check instance permissibility, since this check is expensive, and only needs to be performed once. |
| TI_METHOD_OK | Passed downward from at_apply handler when the thing in the applicative position is a select node. |
| TI_USING_FQNS | The passes beyond the polyinstiator use FQNs to denote all names. The type inferrence engine constructs names from types (ex: re-writing method call ASTs) and needs to know which one to use. |
Definition at line 47 of file TypeInfer.hxx.
| enum UnifyFlagValues |
Flags that control the unifier.
There are different "degrees" of unification that are desirable depending on how the unifier is being driven. These flags control which unifications are permitted.
| UFLG_NO_FLAGS | Any unification permitted. All of Unify('a, T), Unify('a, 'b), and Unify(Ctr('a), Ctr('a)) are OK. |
| UFLG_UNIFY_STRICT | Unification in strict mode. Type variables can only unify with other type variables. Unify('a,T) is rejected, but Unify('a, 'b), and Unify(Ctr('a), Ctr('a)) are OK. |
| UFLG_UNIFY_STRICT_TVAR |
Unification in strict mode. Type variables can only unify with other type variables, and only if the type variables have the same name. That is: no alpha-renaming is permitted. Unify('a,T) is rejected, Unify('a, 'a) is OK, Unify('a, 'b) is rejected, and Unify(Ctr('a), Ctr('a)) is OK.
This mode is used when |
| UFLG_UN_IGN_RIGIDITY |
Unify ignoring rigidity.
A type variable is "rigid" when it's variability is (temporarily) frozen. That is: when it cannot unify with other types. This provides finer-grain control than UFLG_UNIFY_STRICT_TVAR, because some type variables can be allowed to unify while others are held rigid. |
Definition at line 103 of file TypeInfer.hxx.
1.4.7