Re: [Caml-list] whither portability?

[Gerd Stolpmann <info@gerd-stolpmann.de>]

[-- Attachment #1: Type: text/plain, Size: 4204 bytes --]

Am Samstag, den 26.09.2015, 05:48 -0700 schrieb Raoul Duke:
> Exciting to hear! Thank you and your contributors for this work. I
> know there are ways people can be parochial, but I have never been
> able to fathom how the core OCaml team can ignore mobile so actively,
> it seems. It is to sigh, oy veh.

I wouldn't say it was "actively" ignored. It is a matter of resources,
and - to some agree - also a matter of how important you think support
for mobile is. And finally, the devices got first recently so powerful
that it makes a lot of sense to target mobile/desktop/server in similar
ways, in particular with the same dev languages. This is an important
niche for OCaml because the choice of languages on mobile OS is somewhat
restricted.

> * Getting anything working as simply as possible would be a nice first
> step, even if it isn't the most performant. I.e. bytecode. It seems
> Apple has loosened up on that a bit over the years? And I wonder if
> LLVM bytecode would be no problem with them now.

As whitequark already said there is no need to back up to using
bytecode. Both 32 and 64 bit ARM works (the latter is now required for
Apple's appstore). There might be here and there uses for bytecode,
though, e.g. if you need to compile code on the fly.

> * FFI will be essential. It is one thing to have 2+2 working on
> mobile, it is another to be able to get any real app work done.

The FFI works in the normal way. You just need to ensure that you also
cross-compile the wrapped library for the mobile device. If you compile
C files with ocamlc/ocamlopt as driver it just works (and all tools
basing on that work, e.g. ocamlbuild). If you invoke the C compiler
directly you need to ensure to pass the right flags for cross-compiling
(e.g. -arch arm64).

I guess the biggest missing piece here is getting wrappers for the
typical platform libraries.

> * Ideally it has to integrate well with the platform toolchains,
> including the preferred IDEs. E.g. if there's no good installer, if I
> have to do a lot of work to build things, etc., then I'm way less
> likely to even try to use it. I know that is work most people do not
> like to do. I say that empirically.

For the iOS support we are not yet that far.

> * If you can find some commerical users and support, that could help
> drive some of the above issues further faster (although of course the
> vector along which they proceed is subjective).

This is not as you think. The iOS port is actually driven by commercial
users, which has two big advantages: developers have time, and there are
plenty of testing opportunities. These users, however, don't have any
problems with the FFI or need an IDE. This is just a matter of using
development resources well.

Let me just explain for what I need the iOS port. The company I'm
working for developed a query compiler in OCaml for a new database
system. This database backs a UI, and there is also a mobile version of
it. Getting the compiler to mobile is fairly essential for the whole
success of the product. Now, a compiler doesn't need much of the FFI as
it only transforms some data (a query string into bytecode, an int
array). External libs are not really needed. The UI is built with the
platform tools (I think it is still in Objective C), and we deliver the
query compiler simply as a normal library with a C header file to the UI
team.

I guess this is fairly typical of commercial users. There is some highly
complex library written in OCaml providing some functionality you don't
want to duplicate in lower-level languages like Swift (sorry,..., a
matter of perspective). The UI is better to develop with the platform
tools, though (and keep in mind that there is usually a separate UI team
not knowing anything about OCaml).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]