Use type_eff_ext everywhere I was using type_eff (and rename
type_eff_ext into type_eff btw). The rationale is to be able to type alias on polymorphic nodes (cf test/should_fail/semantics/bad_call03.lus, that now have a correct error msg). It also makes to code more compact (no more translation from one to the other), and more general (type_eff_ext being more general than type_eff). User polymorphic nodes should be easy now. move all the code in parsey.mly into parserUtil.ml (ease the debug).
Showing
- src/TODO 5 additions, 0 deletionssrc/TODO
- src/compiledData.ml 13 additions, 57 deletionssrc/compiledData.ml
- src/compiledDataDump.ml 19 additions, 27 deletionssrc/compiledDataDump.ml
- src/evalConst.ml 2 additions, 2 deletionssrc/evalConst.ml
- src/evalType.ml 5 additions, 10 deletionssrc/evalType.ml
- src/evalType.mli 1 addition, 1 deletionsrc/evalType.mli
- src/getEff.ml 1 addition, 1 deletionsrc/getEff.ml
- src/getEff.mli 1 addition, 1 deletionsrc/getEff.mli
- src/lazyCompiler.ml 6 additions, 7 deletionssrc/lazyCompiler.ml
- src/parser.mly 0 additions, 328 deletionssrc/parser.mly
- src/parserUtils.ml 328 additions, 1 deletionsrc/parserUtils.ml
- src/predefEvalType.ml 32 additions, 31 deletionssrc/predefEvalType.ml
- src/predefEvalType.mli 1 addition, 1 deletionsrc/predefEvalType.mli
- src/predefSemantics.ml 25 additions, 25 deletionssrc/predefSemantics.ml
- src/test/should_fail/semantics/bad_call03.lus 2 additions, 0 deletionssrc/test/should_fail/semantics/bad_call03.lus
- src/test/should_work/NONREG/Watch.lus 9 additions, 3 deletionssrc/test/should_work/NONREG/Watch.lus
- src/test/test.res.exp 6 additions, 3 deletionssrc/test/test.res.exp
- src/unify.ml 49 additions, 48 deletionssrc/unify.ml
- src/unify.mli 6 additions, 6 deletionssrc/unify.mli
Loading
Please register or sign in to comment