I want to write an OCaml library which will be used by other programing languages like C or even python.
I not sure it's even feasible, and i guess i need to drop some type safety and add runtime checks to the interface for dynamically typed language.
Is it doable ? Is there tools to achieve this goal to auto-generate bindings ? I think stuffs like Corba do not fit well with ocaml ABI, but I may be wrong.
EDIT : by dropping the runtime requirement and using only languages having a llvm frontend, I could use llvm as a common ABI I guess, but it seems tricky.
OCaml has a FFI to interact with C code. The code for the binding has to be written in C, not in OCaml (which has no direct representation of C values, while C has representations of OCaml values). My advice would be:
On the C side, decide what would be the best interface to export that C programmers would like (or Python programmers writing Python bindings starting from your C interface)
Define a "low-level layer" on the OCaml side that gets your OCaml value as close as possible from the C representation
Write some C wrappers to convert from this low-level OCaml representation to your optimal C representation
The reason for step (2) is to have the step (3) as small as possible. Manipulating OCaml values from the C side is a bit painful, in particular you risk getting the interaction with the Garbage Collector wrong, which means segfaults -- plus you don't get any type safety. So the less work you have to do on the C side, the better.
There are some projects to do some of the wrapping work for you. CamlIDL for example, and I think Swig has some support for OCaml. I have never used those, though, so I can't comment.
If you know to which high-level language you wish to convert your interface to, there may be specialized bridge that don't need a C step. For example there are libraries to interact directly with Python representations (search for Pycaml, not sure how battle-tested their are) or with the Java runtime (the OCamlJava project). A C interface is still a safe bet that will allow other people to create bridges to their own languages.
It is feasible, but you need to understand involved topics, like how the GC works.
Have a look at this: http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html#toc148
You need to be careful about types in the stub code, but otherwise you can keep type safety.
Related
Can anyone recommend me an open-source full OCaml parser?
Essentially, I would like to implement my own type-checker for OCaml. Ideally, the parser is written in OCaml. I would just use it to get the AST of the input program. (it is probably too much to ask for the initial typing environment pre-filled with standard library function signatures)
Use compiler-lib that is distributed with OCaml under QPL license. It has everything needed to create your own compiler (and even has some documentation). compiler-lib is essentially a compiler shipped as library.
Otherwise, you can use camlp4 to get the parsetree, but then you need to reimplement everything else from scratch. But at this case you're not restricted with QPL.
it is probably too much to ask for the initial typing environment pre-filled with standard library function signatures
It is not! See the files typing/predef.ml(i).
As for the stdlib, just use the same one as the compiler, except for pervasive which uses values from Predef, the rest is normal OCaml code without any special cases (except bootstraping, obviously).
I've been reading about F# 3.0 type providers (e.g. here) and it seems that they are based on a kind of compile-time code generation. In that respect I was wondering how they compare against Lisp macros. It would seem that both F# 3.0 type providers and Lisp macros allow user code to execute at compile time and introduce new types available to the compiler. Can anyone shed some light on the issue and nuances involved?
There is some overlap between F# type providers and meta-programming techniques from other languages, but I agree with Daniel that they do not have much in common. F# has some other meta-programming techniques like quotations that are perhaps closer to LISP macros.
In particular:
LISP macros are typically used to transform expressions (you can take a LISP expression and either interpret it or transform it and then execute it). Note that the transformation takes a LISP expression as an input - on the other hand, type providers can only take very limited parameters (strings, integers).
Quotations are more similar. They can be used to process F# expression - you can treat a piece of F# code as data and interpret it or transform it. The transformation takes (a sub-set of) an F# expression, but it typically does not execute it.
Type providers are used purely to generate types. Since LISP is dynamically typed, this is not really a problem that you'd have in LISP. However, it is a sort of code-generation (a form of metaprogramming that you can certainly do in LISP).
An interesting aspect of F# type providers is that they work not only at compile-time, but at design-time, that is, in a way that interacts with the full IDE tooling. Type Providers provide 'types' from an external schematized data source, but the implementation mechanism also enables lots of IDE tooling, including IntelliSense (identifier auto-completion), documentation, data tooltips, etc. Combined with the interactive REPL, this affords easy exploration of unfamiliar data sets in a way that is not quite like the experience in any other language.
F# Type providers are a very specific case of compile time code generation i.e they are meant to solve a specific kind of problem by compile time code generation. They allow you to generate new types at compile time.
LISP macros are a more generic approach to meta-programming and hence cater to a lot of use cases. Macro's basically take input as S-expression (code or data) and emit other S-expression .
So a type provider can be implemented using macro easily, whereas you cannot cover the whole range of "what macros can do" with type providers.
I'm not familiar with Lisp macros, but macros in general are used for meta programming (to save typing and add control constructs to the language). Type providers, on the other hand, generate strongly-typed APIs for external data sources.
I can't think of anything besides compile time "expansion" that they have in common.
I'm new to Vala. I'm not familiar with GObject. As I understand it, GObject was spun off from the GLib project from GNOME. Correct me if I'm wrong.
I do like the syntax and implementation of Vala very much, yet it is not in my intentions to write desktop applications for GNOME.
I also know (think I know) that Vala does not have a standard library other than GObject itself.
So my question is: Can Vala be used without GObject and if it can, is it usable (are there optimal and maintained base libraries for common things like type conversions, math, string manipulation, buffers, etc... available)?
There is some other Vala profiles like Dova and Posix.
TLDR: I recommend using Vala with GLib/GObject, because it was designed on top of them.
While there may be alternative profiles for valac they are either unfinished or deprecated.
The whole point of Vala is to reduce the amount of boilerplate required to write GLib and Gtk+ applications in C.
It also adds some nice other improvements over C, like string and array being simple data types instead of error prone pointers.
It mostly wraps all the concepts present in GObject like:
classes
properties
inheritance
delegates
async methods
reference counting (which is manual in C + GObject, and automatic aka ARC in Vala)
type safety of objects
generics
probably much more ...
All of these concepts can be implemented without using GObject/GLib/Gio, but that would mean to basically rewrite GObject/GLib/Gio which doesn't make much sense.
If you don't want to write GUI applications GLib can be used to write console applications as well, using GIO or GTK+ is optional in Vala, applications work on a headless server as well.
I think that there is even some effort in Qt to eventually switch to the GLib main loop, which would make interoperability of Qt and GLib much easier.
A good example of a framework that uses GLib is GStreamer which is used across different desktop environments as well.
In summary:
GLib is a basic cross platform application framework
GObject is the object system used by the GLib ecosystem
GIO is an I/O abstraction (network, filesystem, etc.) based on GLib + GObject
GTK+ is a graphic UI toolkit based on GLib + GObject + GIO + others
GNOME is a desktop environment based on all the "G" technologies
Vala is a high level programming language designed to reduce the boiler plate neded to use the "G" libraries from the C language.
GTK+ originally came from GIMP and was since split into the different "G" libraries that are the basis for GNOME today.
Vala also has very powerful binding mechanisms to make it easy to write so called "VAPI" files for any kind of C library out there.
With the correct VAPI bindings you don't have to worry about manual memory management, pointers, zero termination of strings and arrays and some other tedious things that make writing correct C code so difficult.
Here is another profile that you can use Aroop. (Note it is still under heavy development). What I hope is it is good if you need high performance. Please check the features here.
Although I do more or less understand what a language binding is, I am struggling to understand how they work.
Could anyone explain how do you make a Java binding for WinAPI, for example?
You'll find much better results if you search for Foreign Function Interface or FFI. The FFI is what allows you to call functions that were written in a different language, i.e., foreign ones. Different languages and runtimes have vastly different FFIs and you'll have to learn each one individually. Learning an FFI also forces you to know a little more about the internals of your language and its runtime than you are ordinarily used to. Some FFIs make you write code in the target language, like Haskell (where FFI code must be written in Haskell), and others make you write code in the source language, like Python (where FFI code must be written in C).
Certain languages don't use the term FFI (though it would be nice if they did). For Java, it's called Java Native Interface, or JNI.
Languages (usually) have defined syntax for calling "native" code. So if you have library that exports method foo(), making a biding would mean that you will create, in you example, Java class with method foo(). That way, you can call MyBinding.foo() from the rest of a code, it will make no difference whether it was pure Java method or compiled C code.
Again for Java, you probably want to look at JNI documentation. Other languages have similar mechanisms. There are tools like SIP that will take bunch of C(++) header files, and produce Python bindings for it. I guess other languages could have similar tools as well.
What is the added value for learning F# when you are already familiar with LISP?
Static typing (with type inference)
Algebraic data types
Pattern matching
Extensible pattern matching with active patterns.
Currying (with a nice syntax)
Monadic programming, called 'workflows', provides a nice way to do asynchronous programming.
A lot of these are relatively recent developments in the programming language world. This is something you'll see in F# that you won't in Lisp, especially Common Lisp, because the F# standard is still under development. As a result, you'll find there is a quite a bit to learn. Of course things like ADTs, pattern matching, monads and currying can be built as a library in Lisp, but it's nicer to learn how to use them in a language where they are conveniently built-in.
The biggest advantage of learning F# for real-world use is its integration with .NET.
Comparing Lisp directly to F# isn't really fair, because at the end of the day with enough time you could write the same app in either language.
However, you should learn F# for the same reasons that a C# or Java developer should learn it - because it allows functional programming on the .NET platform. I'm not 100% familiar with Lisp, but I assume it has some of the same problems as OCaml in that there isn't stellar library support. How do you do Database access in Lisp? What about high-performance graphics?
If you want to learn more about 'Why .NET', check out this SO question.
If you knew F# and Lisp, you'd find this a rather strange question to ask.
As others have pointed out, Lisp is dynamically typed. More importantly, the unique feature of Lisp is that it's homoiconic: Lisp code is a fundamental Lisp data type (a list). The macro system takes advantage of that by letting you write code which executes at compile-time and modifies other code.
F# has nothing like this - it's a statically typed language which borrows a lot of ideas from ML and Haskell, and runs it on .NET
What you are asking is akin to "Why do I need to learn to use a spoon if I know how to use a fork?"
Given that LISP is dynamically typed and F# is statically typed, I find such comparisons strange.
If I were switching from Lisp to F#, it would be solely because I had a task on my hands that hugely benefitted from some .NET-only library.
But I don't, so I'm not.
Money. F# code is already more valuable than Lisp code and this gap will widen very rapidly as F# sees widespread adoption.
In other words, you have a much better chance of earning a stable income using F# than using Lisp.
Cheers,
Jon Harrop.
F# is a very different language compared to most Lisp dialects. So F# gives you a very different angle of programming - an angle that you won't learn from Lisp. Most Lisp dialects are best used for incremental, interactive development of symbolic software. At the same time most Lisp dialects are not Functional Programming Languages, but more like multi-paradigm languages - with different dialects placing different weight on supporting FPL features (free of side effects, immutable data structures, algebraic data types, ...). Thus most Lisp dialects either lack static typing or don't put much emphasis on it.
So, if you know some Lisp dialect, then learning F# can make a lot of sense. Just don't think that much of your Lisp knowledge applies to F#, since F# is a very different language. As much as an imperative programming used to C or Java needs to unlearn some ideas when learning Lisp, one also needs to unlearn Lisp habits (no types, side effects, macros, ...) when using F#. F# is also driven by Microsoft and taking advantage of the .net framework.
F# has the benefit that .NET development (in general) is very widely adopted, easily available, and more mass market.
If you want to code F#, you can get Visual Studio, which many developers will already have...as opposed to getting the LISP environment up and running.
Additionally, existing .NET developers are much more likely to look at F# than LISP, if that means anything to you.
(This is coming from a .NET developer who coded, and loved, LISP, while in college).
I'm not sure if you would? If you find F# interesting that would be a reason. If you work requires it, it would be a reason. If you think it would make you more productive or bring you added value over your current knowledge, that would be a reason.
But if you don't find F# interesting, your work doesn't require it and you don't think it would make you more productive or bring you added value, then why would you?
If the question on the other hand is what F# gives that lisp don't, then type inference, pattern matching and integration with the rest of the .NET framework should be considered.
I know this thread is old but since I stumbled on this one I just wanted to comment on my reasons. I am learning F# simply for professional opportunities since .NET carries a lot of weight in a category of companies that dominate my field. The functional paradigm has been growing in use among more quantitatively and data oriented companies and I'd like to be one of the early comers to this trend. Currently there doesn't an exist a strong functional language that fully and safely integrates with the .NET library. I actually attempted to port some .NET from Lisp code and it's really a pain b/c the FFI only supports C primitives and .NET interoperability requires an 'interface' construct and even though I know how to do this in C it's really a huge pain. It would be really, really, good if Lisp went the extra mile in it's next standard and required a c++ class (including virtual functions w/ vtables), and a C# style interface type in it's FFI. Maybe even throw in a Java interface style type too. This would allow complete interoperability with the .NET library and make Lisp a strong contender as a large-scale language. However with that said, coming from a Lisp background made learning F# rather easy. And I like how F# has gone the extra mile to provide types that you would commonly see it quantitative type work. I believe F# was created with mathematical work in mind and that in itself has value over Lisp.
One way to look at this (the original question) is to match up the language (and associated tools and platforms) to the immediate task. If the task requires an overwhelming percentage of .NET code, and it would require less shoe-horning in one language than another to meet the task head-on, then take the path of least resistance (F#). If you don't need .NET capabilities, and you're comfortable working with LISP and there's no arm-bending to move away from it, keep using it.
Not really much different from comparing a hammer with a wrench. Pick the tool that fits the job most effectively. Trying to pick a tool that's objectively "best" is nonsense. And in any case, in 20 years, all of the currently "hot" languages might be outdated anyway.