OCaml App for iOS 8.1 (Sources)

I coded up a simple OCaml iOS app to run in iOS 8.1. Instructions for downloading, building, and running the app are here:

Portland: Which Way Is Up on iOS?

You can download the sources directly here:

Portland 2.0.3, OCaml app for iOS 8.1 (29 KB)

This is a revamped version of Portland, the first example OCaml iOS app I made a few years ago. For maximum clarity it doesn’t do anything particularly impressive. It really just shows how to code an iOS app in OCaml.

Here are some things I learned while revamping.

• Remember to call caml_main() in your main program (see main.m). If you forget, you’ll get the “undefined atom table” error at link time. I wrote about this in Undefined caml_atom_table.

• If you keep disembodied OCaml values in the Objective C world, remember to register them as global roots using caml_register_global_root. Otherwise you’ll experience chaos at the first GC. I wrote about this in OCaml, Objective C, Rule 4.

• Automatic Reference Counting imposes some restrictions on what you can do in wrapper code. For the Portland example (and probably for many real-world apps) it’s enough to have a table of Objective C objects that are conceptually referenced from OCaml. That is, the table in the Objective C world references the objects as a proxy for references from the OCaml world. You can see the code for this in wrap.m. I hope to write more about this. Maybe you, reader, have some ideas for a better approach.

• Modern day iOS apps are based on View Controllers rather than on Views. In particular, it’s usual to define a custom subclass of UIViewController for each piece of the interface. This is tricky for OCaml on iOS, as it’s not (currently) possible to define an OCaml subclass of an Objective C class. For Portland I’m using an Objective C subclass of UIViewController that delegates to an OCaml object. Here too, this is probably good enough for many real-world apps. I hope to write more about this also.

• There are several cyclic dependencies among the classes of Cocoa Touch used in Portland. To represent them in OCaml I use a common set of definitions named ui.mli, where the cycles can be accommodated using class type a = … and b = … . It seems to me this is a strength of OCaml’s structural typing for objects. That is, it’s possible to define class types independently of particular classes. In this way cycles can be represented without forward-reference loopholes. (However it’s possible that the number of cycles in a full interface to Cocoa Touch would become overwhelming.)

It’s dark, chilly, and wet here by Puget Sound; I’m going to retire now to my tent and my dreams. The next thing on my OCaml-on-iOS schedule is to update to the latest OCaml compiler. I’m getting serious polymathic help on this, as I hope you’ll hear about soon.

If you have any trouble (or success) with the Portland app, or have any other comments, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Comments