Analyzer seems to follow specification Analyzer seems to check things that are left implicit in specification Analyzer is structured around rules - it is easy to see that it does the right thing. Does not compute values twice. No deep nesting of scopes, separate tasks handled in separate places. Error messages display position of error The right error messages is displayed Evaluator is structured around small-step / big-step rules - easy to see that it does the right thing added tabs with tabcount = 8 fixes another minor bug in parser small-step evaluation extension: override (coco_override.fj) in Evaluator: you should replace "newE = apply(eval(newE, t), t)" with "newE = eval(newE, t)" it has the same effect but uses less exception handlers. stupid cast leads to error, not warning (this is reasonable) big-step evaluation why do you use substitution in your Analyzer?! use a context! why do you call analyzer in Evaluator?! use a match on New(C, ...) added comments // big-step evaluation extension: override (override.fj) in Evaluator / case Invoke, I suggest you use a binding pattern x @ New(c,args) in order not to construct New(c,args) again for each occurrence of this in line 64. Your code is very well commented and very readable, good job. extension: override (contra.fj) "hybrid" evaluation -- it's better to choose either small-step or big-step. In big-step, one doesn't use congruence rules at all. In English, the past of "override" is "overridden". You have some duplicated code as a result of the class table being realized as a pure data structure (a map). It might be interesting to make a class out of it. added comments # parser returns immutable.Map big-step evaluation extension: override (Override_covar_result_contravar_Args.fj change your comment "//check overload", overloading is different from overriding your evaluator uses contexts(or: "environments") instead of substitution, that's a good idea. extension: override (contravariant.fj