On Mon, Jul 14, 2014 at 8:50 PM, Jonathan S. Shapiro <[email protected]> wrote: > So let's think about this. In Haskell, ML, and BitC a type definition > introduce a whole bunch of things: > > 1. A type constructor > 2. A value constructor > 3. A "shape" for values > 4. Deconstruction pattern matching rules [sort of] > > Which of these should be distinguished? Is it useful to be able to "publish" > a type without publishing the ability to allocate that type? > > It seems to me this is mostly interesting for boxed types, because you have > to be able to construct an unboxed types in order to make a temporary. > Opaque types give us a type constructor and (for unboxed types) a shape, but > not the others. > > My personal inclination is that we shouldn't distinguish construction, > because I haven't seen a real use case where opacity can usefully be > partial. > > Opinions?
The main theoretical value in distinguishing them is if pattern matching can somehow be extended. However, I'm not sure if that's particularly useful since the main use of pattern matching is the completeness guarantees one gets from the compiler knowing everything. So if pattern matching isn't extensible, or more extremely if pattern matching doesn't exist, I don't see a need to distinguish these. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
