search for: llfunction

...ns: string Value::getName() bool Constant::isNull() bool GlobalValue::isDeclaration() bool GlobalVariable::isGlobalConstant() bool Function::isVarArg() Driver code: val make_constant : unit -> llconstant t val make_global_variable : unit -> llglobalvariable t val make_function : unit -> llfunction t (* typesafe *) value_name (make_constant ());; value_name (make_global_variable ());; value_name (make_function ());; is_null (make_constant ());; is_declaration (make_global_variable ());; is_declaration (make_function ());; is_global_constant (make_global_variable ());; is_var_arg (make_functi...

...pe e = [> `Foo | `Bar ] (* match any polymorphic variant that has a superset of [ `Foo | `Bar ] like [ `Foo | `Baz ] or even `Baz, since without brackets `Baz has the type of all the possible variants. *) So with this we can construct a simplified type hierarchy: type llvalue = [ `Value ] type llfunction = [ llvalue | `Function ] Finally, we'll create a polymorphic type that holds the phantom type: type 'a t And then define functions that work on these types. Since we want a function that can take an llvalue, we need to specify it like this: val use_value: [> `Value ] t -> unit va...

.... Unfortunately most errors are assertions, which we can't hook into. Perhaps though we can recover some type safety. Hypothetically, I can imagine using polymorphic variants just like lablgtk, and type llvalue = [`Value] type lluser = [value | `User] type llconstant = [user | `Constant] type llfunction = [llconstant | `Function] val value_name : [> llvalue] -> string val is_tail_call : [>llfunction] -> bool Would something like this be worthwhile? If we do it right, I think we could be mostly source compatible.

...Value, it will be important to push the ISA routines through all of the layers (esp. for Value), but I think you can implement ISA routines in Ocaml relatively painlessly for Type. > Here's the full example: > > foo.mli: > type 'a t > type llvalue = [ `Value ] > type llfunction = [ llvalue | `Function ] > > val use_value : [> `Value] t -> unit > val use_function : [> `Function] t -> unit > > val make_value : unit -> llvalue t > val make_function : unit -> llfunction t > > Does this sound like it could work, or am I missing somethi...

...can control this by limiting who can > create 't's: > > type 'a t > > type llvalue = [ `Value ] > type llconstant = [ llvalue | `Constant ] > type llglobalvalue = [ llvalue | `GlobalValue ] > type llglobalvariable = [ llglobalvalue | `GlobalVariable ] > type llfunction = [ llglobalvalue | `Function ] > > val value_name : [> `Value] t -> string > val is_null : [> `Constant] t -> bool > val is_declaration : [> `GlobalValue] t -> bool > val is_global_constant : [> `GlobalVariable] t -> bool > val is_var_arg : [> `Function...

On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: > Does anyone know if there is any realistic project using LLVM-OCaml > Bindings? I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: http://www.ffconsultancy.com/ocaml/hlvm/ There are at least two other significant users of LLVM's OCaml bindings, AFAIK. > How is the performance? Performance

Attached are updated LLVM-OCaml Bindings Tutorial from Chris Wailes. (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021804.html) We changed them to work with the latest APIs(LLVM2.6 and the latest LLVM from SVN). Does anyone know if there is any realistic project using LLVM-OCaml Bindings? How is the performance? Jianzhou -------------- next part -------------- A non-text attachment was

..."type 'a whatever". The phantom type would be enough to distinguish everything. For instance, lablgtk has a "type 'a obj" that they use as the base type for all of their variants, which I might copy. 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. What about putting the types (and functions) in modules, like ModuleProvider? It'd be like my scheme to break up llvm.ml into multiple files without actually splitting it...

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type 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

...[ `GlobalValue | `GlobalVariable | `Value ] is not compatible with type 'a The first variant type does not allow tag(s) `Function Bottom up looks like: File "foo.ml", line 21, characters 11-36: This expression has type Bar.llglobalvariable Bar.t but is here used with type ([< Bar.llfunction ] as 'a) Bar.t Type Bar.llglobalvariable = [ `GlobalVariable ] is not compatible with type 'a = [< `Function ] These two variant types have no intersection