
Opam-ios: an OCaml compiler for iOS via opam, with example server code - e_d_g_a_r
https://github.com/fxfactorial/opam-ios
======
loxs
Impressive! It would be great if we also get an Android port... would be the
first sane cross platform mobile framework.

~~~
e_d_g_a_r
It does exist! [https://github.com/whitequark/opam-
android](https://github.com/whitequark/opam-android)

~~~
loxs
Great... it's probably time for me to do some mobile stuff :)

------
melling
It seems that oCaml has been working on iOS for at least 4 years:
[https://news.ycombinator.com/item?id=3740173](https://news.ycombinator.com/item?id=3740173)
yet you hardly hear about it.

Anyone care to discuss long term support? How brittle is it with iOS upgrades,
for example?

Any Swift examples that I can include in my Swift Weekly page?

[http://www.h4labs.com/dev/ios/swift.html?week=0](http://www.h4labs.com/dev/ios/swift.html?week=0)

~~~
e_d_g_a_r
Jeff has been maintaining it since, he just released 4.02.3 which is the
latest available compiler [http://psellos.com/2016/01/2016.01.the-minor-
drag.html](http://psellos.com/2016/01/2016.01.the-minor-drag.html) with iOS
9.2. Not that bad I'd say, that's pretty much bleeding edge. I don't know
about swift because I don't know how to compile swift into an object file.
Swift is not worth the hassle for me right now.

FWIW apparently it will be officially merged into the mainline compiler soon
enough.

------
edwintorok
Have you encountered any problems with the App Store review process due to the
application being written in OCaml? I thought they don't like applications
that are not written in Objective-C much.

~~~
lazerwalker
These days, there are plenty of other frameworks for writing native iOS apps
in languages other than Obj-C/Swift (Xamarin/Mono, RubyMotion, etc).

This wasn't always the case, but IIRC the current review rules only forbid
having a runtime scripting language that isn't JS (since Apple can happily
sandbox JS), but anecdotally even that isn't a problem these days (e.g. plenty
of games use Lua for in-game scripting).

~~~
e28eta
The restriction on scripting says you cannot _download_ and run code, unless
it's executed through WebKit or JavascriptCore. So other languages seem to be
fine as long as the code to run is bundled with the application.

------
akhilcacharya
Okay, I'll bite - why OCaml specifically? Aren't there other FP languages that
cross compile to iOS, is there any advantage to using an ML?

~~~
jordwalke
Here are some things that make ML (and OCaml in particular) a desirable
language for mobile development.

1\. Sound, static typing prevents entire classes of errors. This becomes even
more important when you are shipping an irrevocable binary to users which you
cannot update after the fact.

2\. That same static typing can prove safe the removal of data boxing, and
run-time lookup in order to increase performance.

3\. OCaml (`ocamlopt`) does not run your program in a "Virtual Machine" like
Java - instead it compiles your code more directly into machine code like C++.
Many (but not all) of the other functional languages compilers produce a byte
code, and then rely on a JITed Virtual Machine to (hopefully) optimize your
code at runtime. `ocamlopt` compiles your program into assembly and you can
inspect that assembly ahead of time in order to understand how it will
perform. There's always tradeoffs with this approach, but the benefit is that
you do not need to wait for (or hope for) a JIT to optimize your code (or re-
optimize your code when usage patterns change).

4\. OCaml is strict (as opposed to lazy), fairly close to the metal, and maps
to lower level instructions in a fairly straightforward way - you would not be
very surprised if you were to inspect the assembly. OCaml also has two ways to
create bindings to C code. One way is easy and automated, the other way has
better performance.

5\. OCaml has a reputation for being able to allocate tons of memory at an
impressive rate. To the extent that is true (and I've not yet observed
anything to the contrary) I would imagine that would make it well suited to
building UIs that are rapidly re-rendered.

6\. OCaml has an Objects type system extension which makes it easier to create
bindings to platform APIs (which tend to follow an OO design).

7\. OCaml has two compiler modes: `ocamlc` and `ocamlopt`. Both support
separate compilation, which is indispensable when building UI applications,
where tweaking/reloading is very common. `ocamlc` would be ideal for that
rapid development phase because, although it produces slower programs, it
compiles them significantly faster. `ocamlopt` is ideal for shipping because
it produces faster executables.

8\. OCaml does not require that you write only pure programs. This makes it
much easier to integrate with existing platform/mobile code which is also
typically not pure.

~~~
akhilcacharya
Great response!

------
lindig
The server code in the example allocates a new buffer inside the server loop
at every iteration. Is this intended?

~~~
e_d_g_a_r
No, I mention: Here is a stupid server at the beginning, but let no stone be
unturned...

------
e12e
Nice. This still requires an OS X host? Or is it expected to work under eg:
Linux too?

~~~
e_d_g_a_r
Yes, for now. Although I have also cross compiled the entire iOS toolchain to
Linux, even have objective-C code completion in emacs on Ubuntu! That is
however another blog post and detail that I haven't written down about.

TL:DR It is possible for Linux as well, but haven't done it yet.

~~~
sgrove
Wow, very impressive. Following this closely - thanks for sharing!

