Previous week Up Next week

Hello

Here is the latest OCaml Weekly News, for the week of April 04 to 11, 2017.

  1. REST APIs
  2. error messages in multiple languages ?
  3. Compile and link program who use Toploop
  4. Ocaml Github Pull Requests
  5. Other OCaml News

REST APIs

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00003.html

Sébastien Hinderer asked:
Is there a recommended OCaml library that can be used for interacting
with REST APIs?

It should work over http as well as https.
      
Francois BERENGER replied:
opam mentions ocaml-webmachine:

https://github.com/inhabitedtype/ocaml-webmachine

I'm unsure if it's OK for https however.
      
Hezekiah M. Carty also replied:
If you're asking for client access then there are a few options. One is to the
the ocurl bindings to libcurl:

http://opam.ocaml.org/packages/ocurl/

ocurl is very flexible and requires some extra steps in your code to form the
exact request desired. In return you get a lot of flexibility in how all aspects
of the request are handled. You can use it from standard sequential OCaml, with
OCaml's own threads or cooperatively with Lwt.

Another option is to use one of the cohttp client modules:

http://opam.ocaml.org/packages/cohttp/

cohttp currently works with Lwt, Async, mirage or compiled to javascript. It's
quite straightforward to use, though the documentation can take some effort to
dig through. cohttp also has the benefit of being pure OCaml, including HTTPS
support if you compile with ocaml-tls.

I hope this helps you get started.
      
John McAlpine alse replied:
I'm making a PPX Deriving plugin for this exact purpose! It's called ppx_netblob
and I have a blog post outlining its use here:
https://medium.com/@cb04cf16ac8a/a48f970c9af8 (sending from my phone, so I can't
explain much more about it). I'd love to work with you to help improve it, since
at the moment it's pretty much just suited for a couple of my personal projects.

It can use both http and https as long as your cohttp installation can use them
both
      

error messages in multiple languages ?

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00016.html

Tao Stein asked, spawning a big thread:
I've been teaching OCaml to university students in Beijing. I believe they'd
feel more comfortable if the error messages were in Chinese. Has anyone thought
of implementing multi-language strings in the compiler? So, say with the setting
of an environment variable, the compiler user could receive errors and warnings
in their preferred language. I know it would require a lot of translation work
(crowd sourced?), but the internal language abstraction mechanism would need to
be there too.
      
Gabriel Scherer replied:
This is an interesting question and the issue was discussed in 2012 on the list:

https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00100.html

Currently there is no mechanism in the compiler codebase to have multi-language
strings in the compiler. Alexis Irland proposed a patch in the above thread (
https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00152.html ) that
certainly enabled some kind of parametrization, but unfortunately the patch
files (which were hosted on a personal dropbox) seem lost today. (What I have at
hand is a French translation of the compiler messages made by Jacques-Henri
Jourdan, but without a parametrization mechanism.)

I think that this is an interesting idea and I would personally be willing to
support a well-engineered patch providing the feature (the question of whether
the internationalized messages should be hardcoded in a source file or use a
sort of gettext-like mechanism is delicate), but I don't know the opinion of the
compiler maintainers.
      
Xavier Leroy also replied:
Caml Light, the ancestor of OCaml, was internationalized in this manner.  It
had messages in English, French, German, Spanish and Italian.  Curious or
nostalgic minds can have a look at the text file containing the translations:

https://github.com/camllight/camllight/blob/master/sources/src/camlmsgs.txt

and at the i18n engine itself, which was just a wrapper around "printf" that
used the english format message as an index into the translations:

https://github.com/camllight/camllight/blob/master/sources/src/compiler/interntl.ml

This implementation was pretty short and sweet, if I may say so myself, and
possibly easier to use than gettext because by construction the english
message was always available, even if translations were missing by mistake.

Yet it was a lot of work, and quite painful, to keep the message file and
the translations up to date.  Keep in mind that Caml Light had perhaps
1/10th as many messages as OCaml does.  So, the chances of getting i18n to
work for OCaml look thin.  One advantage for me, though, is that it would
make it harder to add new warnings :-)

Your Caml historian,
      
Sébastien Hinderer then said and Xavier Leroy replied:
>> This implementation was pretty short and sweet, if I may say so myself, and
>> possibly easier to use than gettext because by construction the english
>> message was always available, even if translations were missing by
>> mistake.
> 
> I am not following you here. Isn't that exactly the behaviour gettext
> provides?

Oops, yes, you're probably right.  I was confusing gettext with the (early?)
Java i18n library where every message was to be given a unique, short
identifier, then be looked up in a resource file.
      

Compile and link program who use Toploop

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00030.html

Paul Lachat asked:
I would like to use functions of the toplevel
(https://github.com/ocaml/ocaml/blob/trunk/toplevel/toploop.ml)

I've tried to compile this code just to understand how I can link the toploop
file with my program :
____
test.ml :

let _ =
  let lb = Lexing.from_string "let x = 10;;" in
  let ppf = Format.std_formatter in
  try
    List.iter
      (fun phr ->
        if not (Toploop.execute_phrase false ppf phr) then raise Exit)
      (!Toploop.parse_use_file lb)
  with
  | Exit -> ()
  | x -> Errors.report_error ppf x

____

I've test :

[-] ocamlc -I +compiler-libs -o test.out test.ml

[*] File "test.ml", line 1:
Error: Error while linking test.cmo:
Reference to undefined global `Toploop'

____

So I create test.cmo with :
[-] ocamlc -I +compiler-libs -c test.ml, but I don't know where to find
"toploop.cmo".

I use Ocaml 4.03.0 with Opam.
In ".opam/4.03.0/lib/ocaml/compiler-libs/" I have "toploop.cmi", "toploop.cmti"
and "toploop.cmt", but no "toploop.cmo" to link to the program.

I've seen this file ".opam/4.03.0/lib/ocaml/compiler-libs/ocamltoplevel.cma",
but I don't know if it's usefull.

I think it's possible to use Toploop. In this post,
https://stackoverflow.com/questions/33291754/eval-a-string-in-ocaml, they seems
to have find a way to compile a program who use Toploop. But I would like, if
possible, to avoid dependecys like ocamlbuild.

____

So, I would like to know how I can compile this program ?
      
Nicolás Ojeda Bär replied:
You just need to link in ocamltoplevel.cma by adding it to the command-line

ocamlc -I +compiler-libs ocamltoplevel.cma -o test.out test.ml

(the compiler will be able to find this file thanks to the "-I +compiler-libs"
flag).
      

Ocaml Github Pull Requests

Gabriel Scherer and the editor compiled this list:
Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.

- Arg.align: allow to change the "alignment" separator
  https://github.com/ocaml/ocaml/pull/1147
      

Other OCaml News

From the ocamlcore planet blog:
Here are links from many OCaml blogs aggregated at OCaml Planet,
http://ocaml.org/community/planet/.

Full Time: Software Developer (Functional Programming) at Jane Street in New
York, NY; London, UK; Hong Kong
 http://jobs.github.com/positions/0a9333c4-71da-11e0-9ac7-692793c00b45

Version 0.0.2 of the Frama-Clang plugin plugin is available for download.
 http://frama-c.com/index.html
      

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.


Alan Schmitt