On Dec 27, 2014 3:31 PM, "Matt Oliveri" <[email protected]> wrote: > Yes, that makes perfect sense. I am only objecting to the sense I got > from David that there's something wrong with closed variant types for > modular compilation.
Nope, nothing is wrong with closed variant types, but systems with late-binding often lack closed types. Even a type without subtyping is only closed inside a sealed atomic compilation module that defines them. (Or via some static compile time binding construct) My point is --> I'm not aware of any type construct in any late binding runtime which makes a distinction about how a type can be used based on whether it is closed or not. (Which obviously doesn't mean it doesn't exist or can't be done.. Probably nemerle.net has done it) AFAIK, CLR can easily handle such a construct. CLR enums and structs forbid subtyping, and assemblies are atomic sealed units of compilation. Therefore, enums and structs are closed inside the assembly that defines them. Which means an exhaustive switch could exist (but only over closed enums defined in the same assembly). In the JVM, I suppose the closure unit is the class. As far the utility of this and shap's comment about all scenarios involving subtyping. We are thinking about different situations. I'm referring to using variant/match (or enum/switch) as a code structuring tool, as is commonly done with pattern matching in whole-program-compilers. The last time I personally ran into this in C# (in a 3d bounding volume hierarchy implementation), I use a closed/internal enum <https://github.com/jeske/SimpleScene/blob/master/SimpleScene/Util/ssBVH/ssBVH_Node.cs#L210> connected two switch statements (1 <https://github.com/jeske/SimpleScene/blob/master/SimpleScene/Util/ssBVH/ssBVH_Node.cs#L255>, 2 <https://github.com/jeske/SimpleScene/blob/master/SimpleScene/Util/ssBVH/ssBVH_Node.cs#L307>), and cringed at the "default: throw NotImplemented" and lack of exhaustive checking. I find this kind of pattern fairly common, which is I suspect why programmers like pattern matching, especially for it's *exhaustive checking*. To replace the above example with the visitor pattern would make the code huge, slower, and hard to follow -- because the case-implementations would have been spread far apart. I think the visitor pattern is primarily used for serialization.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
