Hi all,
I'm considering using ocaml for some experiments I want to try -- does
the binding currently support reading existing bitcode, or just
generating it? I want to try out some program transformation ideas that
would probably be rather easier to express in ocaml than C++.
Thank you in advance,
Sarah Thompson
No, but it's easily added…
— Gordon
Gordon Henriksen wrote:
Is it reasonable for me to hack on this, or would you rather do it yourself? (If the latter, you would be very much in my debt...)
Or the other way around, or something. 
[s]
I'm adding it now.
— Gordon
I'd really appreciate JIT support from OCaml while you're there and if you'd
like to send me some money as well that'd be great. 
Incidentally, should more OCaml stuff beyond the bindings be part of LLVM or
would it be better to fork them into a separate project and alleviate some
stress from Chris et al? Might be easier if a community want to tinker with
ideas, e.g. for a higher-level interface.
Hi Jon,
Is it reasonable for me to hack on this, or would you rather do it yourself? (If the latter, you would be very much in my debt...)
Or the other way around, or something.
I'd really appreciate JIT support from OCaml while you're there and if you'd like to send me some money as well that'd be great.
Well, this commit should be a good template for adding bindings for new libraries.
Incidentally, should more OCaml stuff beyond the bindings be part of LLVM or would it be better to fork them into a separate project
Can you be more specific than "stuff"?
and alleviate some stress from Chris et al? Might be easier if a community want to tinker with ideas, e.g. for a higher-level interface.
Chris doesn't have Ocaml installed, AFAIK, so I don't know how much of a concern that is. I'd probably be the first line of review.
— Gordon
Gordon Henriksen wrote:
Hi Jon,
Is it reasonable for me to hack on this, or would you rather do it yourself? (If the latter, you would be very much in my debt...)
Or the other way around, or something.
I'd really appreciate JIT support from OCaml while you're there and if you'd like to send me some money as well that'd be great.
Incidentally, should more OCaml stuff beyond the bindings be part of LLVM or would it be better to fork them into a separate project
Can you be more specific than "stuff"?and alleviate some stress from Chris et al? Might be easier if a community want to tinker with ideas, e.g. for a higher-level interface.
Chris doesn't have Ocaml installed, AFAIK, so I don't know how much of a concern that is.
I'd be inclined to push for at least the binding staying linked with LLVM's releases, at least from a version control point of view, or it would get difficult to keep them working together reliably. As for other ocaml-based tools, I'm not so concerned, though obviously if they turn out to be very useful it might make sense to distribute them with the core release.
[s]
Sarah,
I thought there'd be more interest in the C bindings, personally, so I'm pleasantly surprised by the vigorous response to the Ocaml bindings. I suppose the primary audience for C bindings are FFIs for other languages, so perhaps it's not an entirely surprising result in retrospect.
Regardless, I don't think you need to worry about them going anywhere now that the portability problems have been ironed out of the makefiles.
Incidentally: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071210/056155.html
— Gordon
I'm happy to continue letting Gordon worry about it
-Chris
> Incidentally, should more OCaml stuff beyond the bindings be part of
> LLVM or would it be better to fork them into a separate projectCan you be more specific than "stuff"?
I'm thinking of a library that compiles an AST represented by an OCaml data
structure into the appropriate calls to LLVM. Ultimately, with support for
exceptions and a run-time.
> and alleviate some stress from Chris et al? Might be easier if a
> community want to tinker with ideas, e.g. for a higher-level
> interface.Chris doesn't have Ocaml installed, AFAIK, so I don't know how much of
a concern that is.
Wow, how does he autogenerate that C++ code without OCaml?
Since that ASTs are by definition language-specific, such should probably be a separate project because LLVM itself is language-agnostic.
— Gordon
Well, I'd like this to factor out commonality from the implementations of all
managed languages (everything from C++ to Lisp) so I think it should express
a typed language with typical control-flow constructs (including exceptions),
only first-order functions and parametric polymorphism/generics. The generics
should be handled by JIT compiling type-specialized functions on demand. This
representation should also be cross-platform.
This could be a language in itself, of course, just as MSIL is but I think
you'd want to add pattern match compilation, higher-order functions, an
object system and so forth on top of this to make it useful.
Hi Jon,
In this direction, PyPy and Reid's HLVM projects may be of interest to you.
— Gordon
Yes. I've had a look at both of those but they only seem to cater for
dynamically-typed languages.
Hi Jon,
> Hi Jon,
>
> In this direction, PyPy and Reid's HLVM projects may be of interest to
> you.Yes. I've had a look at both of those but they only seem to cater for
dynamically-typed languages.
For HLVM, that is correct initially, but there's no intent to limit HLVM
to dynamically-typed languages. It is intended to be, essentially, an
aid to creating any programming language faster. This probably isn't
apparent in the (woefully out of date) documentation.
Reid.