search for: ll_____

...These 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. I don't have a better suggestion than just naming the variant sum types Llvm.ll_____. I considered some other options, but decided I'm not fond of them in practice. Thanks, Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080315/7c624f16/attachment.html>

...oid 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. > > I don't have a better suggestion than just naming the variant sum types > Llvm.ll_____. I considered some other options, but decided I'm not fond of > them in practice. I think we'd need only one definition of "type 'a whatever". The phantom type would be enough to distinguish everything. For instance, lablgtk has a "type 'a obj" that they use...

On Mar 15, 2008, at 17:49, Erick Tryzelaar wrote: > 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: > > type 'a t > > type llvalue = [ `Value ] > type llconstant = [ llvalue |

So just to compare, here are two different typesafe phantom type implementations. One is bottom down, the other bottom up. This is an example of the following functions: string Value::getName() bool Constant::isNull() bool GlobalValue::isDeclaration() bool GlobalVariable::isGlobalConstant() bool Function::isVarArg() Driver code: val make_constant : unit -> llconstant t val