Re: [Caml-list] OCaml && COCOA-Environment (Mac-OS-X/GUI)

[Paul Snively <psnively@mac.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 22, 2005, at 4:12 PM, Jacques Garrigue wrote:

> This actually looks pretty impressive.
> And it isn't really stagnant: their approach is to generate everything
> automatically, so once it works, there are not many changes left to
> do. Yet they could do with a bit more documentation (but I shouldn't
> be the one to say so :-)
>
> So they have this wonderful interface compiler, which slurps all the
> objective C headers, and produces a strongly typed Haskell interface.
> With a bit of syntactic sugar, you end up with something you can
> actually write in; actually you write objective C with haskell syntax,
> which is a bit weird, but works.
>
This is exactly what I have in mind: take advantage of Forklift's 
external annotations to header files. So: revise Forklift to parse 
Objective-C headers, write (external) annotations to Apple's headers, 
and use Forklift to generate the O'Caml wrappers. Indeed, part of the 
point is very much to end up in a position where changes Apple makes to 
the headers necessitate hopefully minor revisions to the annotations 
and an automated regeneration.

> Of course, there is a catch: the generated interface is huge.
> So you end up with this 172-line haskell application (a simple
> editor), which compiles to a 11MB binary (not including the
> gnustep/cocoa shared libraries). The binary libraries (*.a) they
> install sum up to a whooping 33MB!
>
Ouch! Is there no dead-code stripping?

> I suppose the same kind of integration could be done with ocaml.
> In particular Objective C is dynamic enough that you can do lots of
> things with a tiny runtime support, and then introduce all your types.
> The problem is that it's not clear whether it would match nicely with
> the ocaml object system.
>
Mike Hamburg got some distance with his runtime library, which 
naturally relied on Obj.magic. It seemed relatively tight and elegant, 
but of course he's since commented on some runtime overhead concerns 
that, IIRC, he believes might be ameliorated by having better type 
information, which presumably would come from the FFI. So we seem to be 
at something of a Catch-22, at least until some concrete progress on 
deriving type information via an FFI is accomplished. I note with 
interest Jeff Henrikson's comments and regret that I have not yet had 
sufficient time to investigate them beyond reading them. Hopefully this 
weekend will provide some time to follow up.

> Cheers,
>
> Jacques Garrigue
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIeO9cACgkQO3fYpochAqJttQCgyWwDtq8zJbp4iAGNkyDWQIOL
IQ4An2fV2lQezGjzgjVdfvUBkrOB8q83
=1S2R
-----END PGP SIGNATURE-----