On Fri, Jun 12, 2015 at 3:57 AM, Matt Oliveri <atma...@gmail.com> wrote: > On Fri, Jun 12, 2015 at 2:43 AM, Keean Schupke <ke...@fry-it.com> wrote: >> In a functional language I would use a disjoint union for the node type (as >> the tag in the disjoint union encodes the necessary runtime polymorphism). >> To try and use types to encode this, where you are pushing runtime >> polymorphism into the type system, and then to try and ignore that type >> using a heterogeneous list (lime a list with existential type) seems >> mistaken to me, when the fact is this is necessarily runtime polymorphism, >> and that is most simply and directly encoded as a disjoint union type. You >> gain nothing by trying to be tagless, as the type system will have to insert >> hidden tags to recover the runtime polymorphism. It seems a classic example >> of obfuscation by making things more complex than they needs to be, when the >> simple solution is the right one. > > Keean, the goal here is not to improve performance over the > one-big-tagged-union option. It is indeed clear that you can't do > better, if you want AST nodes to be useful. The goal is to know, > statically, that the parsed AST will always conform to the constrained > structure allowed by the original CFG.
To possibly help reach an understanding regarding refinement types, I should probably point out here that refinement types are ideal when you're using types _only_ for static guarantees, like we are here. One should not expect refinement types to help with optimization; they're _too_ expressive. You'd have no idea what to do with the information refinements can provide in general. On the other hand, you never have to worry about refinement types hurting performance either, because you implement the unrefined type system; the refinements just get erased. This is why, Keean, it seems so strange to me to try to use type classes for refinements. Type classes definitely impact how code gets implemented. At least in Haskell. Refinements definitely do not. At least if you mean the same thing as me by "refinements". _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
