
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 16, 2008, at 03:21, Erick Tryzelaar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen <<a href="mailto:gordonhenriksen@mac.com">gordonhenriksen@mac.com</a>> wrote:</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">After some experimentation, I'd prefer the closed system. LLVM has some type <span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in the closed model.</span></blockquote><br>It looks like you might be right, and open variants might not be able to handle the pseudo-shared functions like llvm::CallInst::doesNotReturn and llvm::InvokeInst::doesNotReturn. We can't do the naive<br><br>val does_not_return : [> `CallInst | `InvokeInst] t -> bool<br><br>Like we can with closed variants:<br><br>val does_not_return : [< llcallinst | llinvokeinst] t -> bool.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>Exactly.</div><br><blockquote type="cite"><blockquote type="cite">Please use 'a Llvm.ty for Type and 'a Llvm.v for Value to save typing. These <span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">choices avoid conflicting with the common type binding t and the language keyword val, but promote these important types to the type names into the Llvm module (likely open'd) for brevity's sake.</span></blockquote><blockquote type="cite"></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">For instance, lablgtk has a "type 'a obj" that they use as the base type for all of their variants, which I might copy.</span></blockquote><div><br class="webkit-block-placeholder"></div><div>GTK+ has GtkObject at the root of its type system—an (open) tree of types. Value and Type have truly disjoint class hierarchies with no interfaces in common—a (closed) forest of types. Not only that, but there is cause to consider qualifying values with <i>two</i> phantom variants, which is not the case for types.</div><div><br class="webkit-block-placeholder"></div><div>Please continue to use different abstract types, as we currently do (lltype and llvalue).</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite">I think we'd need only one definition of "type 'a whatever". The phantom type would be enough to distinguish everything. We can even hide this type by naming the variants something like "llfunction_variants" and then "type llfunction = llfunction_variants obj" to have roughly the same interface as before.</blockquote><br></div><div>I am not convinced that your type definition there would work right. If it is truly compatible (user code can accept and return values of that type, let bind them, put them in structs and refs), please proceed (and provide such aliases for all variants). However, if it's only 'sort of' compatible, please skip the extra layer of complexity.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><blockquote type="cite">I don't have a better suggestion than just naming the variant sum types <span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Llvm.ll_____. I considered some other options, but decided I'm not fond of them in practice.</span></blockquote></blockquote><blockquote type="cite"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1;"><br class="webkit-block-placeholder"></span></div></blockquote><blockquote type="cite">What about putting the types (and functions) in modules, like ModuleProvider?</blockquote><div><br class="webkit-block-placeholder"></div><div>I do like the submodules for keeping odd classes in their own namespace, but I rather like how users of the core IR functions read in the functional style. Besides, I don't want to change my (user) code without good reason. (By contrast, getting type checking is a good reason to change my type declarations.)</div><br><blockquote type="cite">It'd be like my scheme to break up llvm.ml into multiple files without actually splitting it up :) Then you could open Llvm and reference Value.t without obscuring anything. We could even open or abbreviate the module name in scope for even shorter function names than before.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>I thought <font class="Apple-style-span" face="Courier">[<Value.llconstant] Value.t</font> was getting to be too verbose. Note that you don't need to worry about naming conflicts with the variants since these are all in the <font class="Apple-style-span" face="Courier">llvm::</font> namespace in C++.</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">I was unsure of if it were better to add new functionality in the top level or in a module, so I erred towards module.</span></blockquote></div><div><br class="webkit-block-placeholder"></div><div>Let's angle to keep the IR in the top-level and the rest in submodules. I think that creates a nice balance of brevity (and compat) for common, core functions and explicitness and isolation for the more obscure features of the infrastructure.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Oh and one last thing that I've been meaning to ask for a long long time. Do you think we could change the ordering of some of the arguments? The builder functions, like:</span></blockquote><div><br class="webkit-block-placeholder"></div><div>At this point, please don't change it.</div><br><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">— Gordon</span></div><div apple-content-edited="true"> </div><br></body></html>