On Fri, Feb 27, 2015 at 2:18 PM, Keean Schupke <[email protected]> wrote:
> Now I have started thinking about implementation, I am working on a > nano-pass compiler, so the logical thing for me is to have the languages > like this: > > L1 - has arity-abstract and arity-concrete types. Concrete arity here is > only used when we cannot modify the definition. So arty-abstract types have > all the optimisations discussed by AST rewrite available. > > L1 => L2 replace all abstract types using AST rewrite so that we prefer > minimal currying for best performance. > > L2 - only has artiy-concrete types. > > > So if L2 type-checks we know we have successfully removed all > arty-abstract types, and we now respect all specified concrete-parities and > calling conventions. > > Can you see any problems with this approach? > This is basically similar to what I'm going to do in BitC, except that in my L1 all *definitions* will have concrete arity. If L1 has the capacity to state concrete arity, then L2 is a subset language rather than a separate language. That's a very good thing, since it means you can preserve the same type system throughout. BitC manages to do that all the way down to the pass where letrec gets flattened. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
