From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id A33307EE49 for ; Thu, 19 Sep 2013 10:11:52 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYBAHewOlLB/BfUnGdsb2JhbABbgz/Bf4E4DgEBAQEBCBQJPIIlAQEFODsFEQsYCRYPCQMCAQIBRQYBDAYCAQGIAwi5ZY9uhB4Dl3yGMY5q X-IPAS-Result: AnYBAHewOlLB/BfUnGdsb2JhbABbgz/Bf4E4DgEBAQEBCBQJPIIlAQEFODsFEQsYCRYPCQMCAQIBRQYBDAYCAQGIAwi5ZY9uhB4Dl3yGMY5q X-IronPort-AV: E=Sophos;i="4.90,935,1371074400"; d="scan'208";a="27360284" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Sep 2013 10:11:52 +0200 Received: from [192.168.1.101] ([92.151.78.110]) by mwinf5d09 with ME id SwBq1m00E2Nnnrw03wBqj7; Thu, 19 Sep 2013 10:11:51 +0200 Message-ID: <523AB1C7.1050509@frisch.fr> Date: Thu, 19 Sep 2013 10:11:51 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Gour , caml-list@inria.fr References: <20130910230928.2d51cd39@atmarama.noip.me> <20130911073854.GA4499@kerneis.info> <20130911102024.6a311672@atmarama.noip.me> <1378899769.11824.15.camel@thinkpad> <20130918134229.37a0df52@atmarama.noip.me> In-Reply-To: <20130918134229.37a0df52@atmarama.noip.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options We have done some experiments running LexiFi's core libraries (symbolic manipulations of terms representing financial contracts) in the browser, using js_of_ocaml. We also played with dynamic GUI generation directly in the browser, based on our runtime type extension (which works fine with js_of_ocaml). Overall, we were impressed by the easiness to integrate js_of_ocaml (no need to patch the compiler or do big changes to the build system) and its faithfulness to the semantics of OCaml. Really no big bad surprises, and it was amazing to see a complex piece of software running in the browser. js_of_ocaml opens many interesting doors for using OCaml in web development! (((Some points which required some special care: - Support for C primitives. Each primitive called by the bytecode needs to have a Javascript implementation. Since LexiFi's version of OCaml is most often synchronized with OCaml's trunk than with a stable release, we had to implement the new primitives. This raises the general point that js_of_ocaml will need some active maintenance, even if the OCaml bytecode itself is very stable across versions. - A tiny semantic difference: in OCaml, the expression "String.unsafe_get s (String.length s)" returns '\000', which gives an efficient way to iterate over a string without checking for the end-of-string condition explicitly. This hack (which is also used in the stdlib module, btw) does not work with the way strings are represented in js_of_ocaml. That said, we were quite happy to see that other low-level hacks we do with the runtime representation of values worked well (setting a block tag to Object_tag to force generic comparison and hashing to use the second field; or playing with the representation of method tables to memoize method calls). - The lack of weak hash tables, which we use quite a lot. I wonder if Firefox's experimental WeakMap could be used to simulate them (and if other browsers will get similar features). - Reliance on Camlp4 for interacting with Javascript. Getting rid of this dependency was our first internal use of -ppx! ))) Alain On 09/18/2013 01:42 PM, Gour wrote: > On Wed, 11 Sep 2013 13:42:49 +0200 > Gerd Stolpmann wrote: > >> We would need an HTML5 binding so the programmer wouldn't see the >> Javascript part. > > In my search for adequate GUI bindings I've found out about OCaml > bindings (https://github.com/astrada/ocaml-extjs) for ExtJS > (http://www.sencha.com/products/extjs/) so wonder what is your > experience with js_of_ocaml in generall and/or ExtJS? > > > Sincerely, > Gour >