On 27 February 2015 at 21:07, Jonathan S. Shapiro <[email protected]> wrote: > > Curious how you know about that work. He hasn't been all that public > about it.
I am from an electronic engineering background, and CPU architecture is something I am interested in. They have put stuff about it on the Web, and I can't remember what I was researching when I found it. As I've said several times, some of the transforms you have discussed as > long as you can see all the code involved and rewrite it accordingly. > I realise this, sorry if I'm a bit slow at thinking this through, I am just trying to understand why these things are needed. 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? Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
