At the moment, all constraints are generated out of ConstraintManager, and once constraints are generated, we put them in ConstraintManager without any checking.
Professor Dietl and I discussed about current features of ConstraintManager, and we think that it is may be a good idea that we can create and check constraints inside ConstraintManager.
For example, we can add method public void addSubtypeConstraint(Slot subtype, Slot supertype) in ConstraintManager. The method generates a SubtypeConstraint for the two slots, and do some checking:
If supertype is ConstantSlot and the value of it is the top type, then we don't need to generate anything, and same for if subtype is bottom type.
If both supertype and subtype are ConstantSlot, then we check whether the two types satisfy subtype type rules, if they don't, the ConstraintManager reports type incompatible error.
The problem for this implementation is if we want to use report method in SourceChecker to report error, we need the second parameter of the method to indicate the location of the problem, but we cannot get that information from instance of Slot. Passing the Tree node to ConstraintManager through all the callers may need a lot of refinement. So we may need to think a better way to refine it.
At the moment, all constraints are generated out of
ConstraintManager, and once constraints are generated, we put them inConstraintManagerwithout any checking. Professor Dietl and I discussed about current features ofConstraintManager, and we think that it is may be a good idea that we can create and check constraints insideConstraintManager. For example, we can add methodpublic void addSubtypeConstraint(Slot subtype, Slot supertype)inConstraintManager. The method generates aSubtypeConstraintfor the two slots, and do some checking: If supertype isConstantSlotand the value of it is the top type, then we don't need to generate anything, and same for if subtype is bottom type. If both supertype and subtype areConstantSlot, then we check whether the two types satisfy subtype type rules, if they don't, theConstraintManagerreports type incompatible error. The problem for this implementation is if we want to usereportmethod inSourceCheckerto report error, we need the second parameter of the method to indicate the location of the problem, but we cannot get that information from instance ofSlot. Passing theTreenode toConstraintManagerthrough all the callers may need a lot of refinement. So we may need to think a better way to refine it.