<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 15, 2008, at 17:49, Erick Tryzelaar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">The other way is top down. This lets us extend our types, but sacrifices some type safety, as we're saying that the arguments are a superset of the variants. We can control this by limiting who can create 't's:</span></blockquote><blockquote type="cite"><br>type 'a t<br><br>type llvalue = [ `Value ]<br>type llconstant = [ llvalue | `Constant ]<br>type llglobalvalue = [ llvalue | `GlobalValue ]<br>type llglobalvariable = [ llglobalvalue | `GlobalVariable ]<br>type llfunction = [ llglobalvalue | `Function ]<br><br>val value_name : [> `Value] t -> string<br>val is_null : [> `Constant] t -> bool<br>val is_declaration : [> `GlobalValue] t -> bool<br>val is_global_constant : [> `GlobalVariable] t -> bool<br>val is_var_arg : [> `Function] t -> bool<br></blockquote></div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Trebuchet MS; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><br class="webkit-block-placeholder"></div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Ah, I get it now. <font class="Apple-style-span" face="Courier">type b = [ a | `B ]</font> is idiomatic type theoretician for <font class="Apple-style-span" face="Courier"><i>b t</i></font><i> is a subclass of </i><font class="Apple-style-span" face="Courier"><i>a t</i></font>. This seems slightly a hack, using sum types to do exactly the opposite of what they're designed for. :)</div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><br class="webkit-block-placeholder"></div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I think you want to use the sum types for parameter typing; [> `GlobalValue ] is not compatible with llconstant.</div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><br class="webkit-block-placeholder"></div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><blockquote type="cite">Bottom up. The advantage of this one is that we'll always be typesafe since we're saying the arguments must be a subset of the specified variants, and thus all the variants are closed. The disadvantage is that if we want to add another type we have to edit all the type definitions. This also means that we can't add another library that subclasses from something and still use these functions:<br><br>type 'a t<br>type llfunction = [ `Function ]<br>type llglobalvariable = [ `GlobalVariable ]<br>type llglobalvalue = [ llfunction | llglobalvariable ]<br>type llconstant = [ `Constant ]<br>type llvalue = [ llconstant | llglobalvalue ]<br><br>val value_name : [< llvalue] t -> string<br>val is_null : [< llconstant] t -> bool<br>val is_declaration : [< llglobalvalue] t -> bool<br>val is_global_constant : [< llglobalvariable] t -> bool<br>val is_var_arg : [< llfunction] t -> bool<br></blockquote><div><br class="webkit-block-placeholder"></div><div>I find this intensely more intuitive. The LLVM IR is closed and self-contained within the VMCore library (modulo a couple of private User subclasses in the bitcode libraries), so that's not a problem.</div><div><br class="webkit-block-placeholder"></div></div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Clearly, these are syntactically very similar. With my above comment, the difference is literally > vs. <. Since the IR is closed, they're semantically similar as well. The extensible method is clearly preferable for extensible hierarchies, should we have cause to expose any methods on them. Passes are an example of this.</div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br class="webkit-block-placeholder"></div></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">What do the respective type errors look like?</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "></div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">— Gordon</div></span> </div><br></body></html>