[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Apr 25 06:25:17 PDT 2017
Hello,
Here is the latest OCaml Weekly News, for the week of April 11 to 25, 2017.
Sorry for the hiatus last week, I was away for vacations.
1) error messages in multiple languages ?
2) support for OCaml on unusual platforms (ia64-hpux, etc.)
3) OCaml jobs at genomics company in New York City
4) Ocaml 4.04.1 released
5) release of batteries-2.6.0
6) New release of Menhir (20170418)
7) Lwt 3.0.0 ? monadic promises and concurrent I/O
8) PPX is harmful to our community in the long term
9) BuckleScript 1.7
10) CUFP 2017 Call for Tutorials
11) Ocaml Github Pull Requests
12) Other OCaml News
========================================================================
1) error messages in multiple languages ?
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00042.html>
------------------------------------------------------------------------
** Continuing this thread, Richard Jones said:
It looks like people have already mentioned getttext.
I want to add that OCaml already has an excellent gettext
implementation. No need to reinvent any wheels.
<https://forge.ocamlcore.org/projects/ocaml-gettext/>
We use it every day in libguestfs, an example picked at random
(there are thousands more):
<https://github.com/libguestfs/libguestfs/blob/master/v2v/input_libvirt.ml#L39>
Therefore you might think I'd be very exciting about having the OCaml
compiler messages being localized. That not so much. I find that it
makes it considerably easier to search for error messages, and also to
help people, if they are in a single language. It's for this reason
that we don't translate debugging and other internal messages in our
tools. (But being an English native speaker it's a lot easier for me,
so take this with a pinch of salt.)
** Gabriel Scherer then replied:
> I find that it makes it considerably easier to search for error messages
On this specific topic, I would be interested in having OCaml compiler error
messages numbered, just as warnings already are, precisely because it makes it
much easier to reference them (is robust to change of wording), and for example
look up a specific error in the manual for further explanations -- we recently
started doing this for warnings, see
<http://caml.inria.fr/pub/docs/manual-ocaml/comp.html#sec270> .
========================================================================
2) support for OCaml on unusual platforms (ia64-hpux, etc.)
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00044.html>
------------------------------------------------------------------------
** Fabrice Le Fessant announced:
As the Sparc native backend was just removed today from OCaml, it might be
interesting for some of you to know that OCamlPro recently resurrected the ia64
native backend and ported it to HP-UX for one of its customers. The whole story
is here:
<http://www.ocamlpro.com/porting-ocaml/>
So, if you are interested in using OCaml on new architectures, or new versions
of OCaml on architectures that are no longer officially supported, just contact
us.
========================================================================
3) OCaml jobs at genomics company in New York City
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00052.html>
------------------------------------------------------------------------
** Ashish Agarwal announced:
Solvuu is a startup developing software for the life sciences industry. Our core
technology is based on ideas from type theory and functional programming, and
our software is implemented almost entirely in OCaml. We develop software across
the full stack: cloud infrastructure management, job scheduling, data management
and security, clients and servers for many APIs, rich websites, and much more.
We are currently hiring 2 full-time OCaml programmers in New York City. We are
open to a spectrum of qualifications, but basically the more OCaml you know the
better. Ideal candidates will have at least 5 years of experience developing
production OCaml software, whether in industry or as an academic active in the
open source community. We are offering great compensation packages that include
salary, equity, and the usual things like health care and a ping pong table.
Most importantly, you will build great technology to advance society in areas as
important as cancer treatment, drug discovery, and agriculture. And you get to
do all of that in Manhattan, one of the most vibrant and beautiful cities in the
world.
To apply, please contact me directly (ashish at solvuu.com) with your resume/CV.
International applicants are welcome, but the reality is getting a visa will be
challenging. We are willing to try and may explore options for exceptional
candidates.
About Genomics: Our primary focus is on genomics, an industry driven by a
dramatic decrease in the cost of DNA sequencing. Fifteen years ago it cost
$100,000,000 to sequence a single human genome, today it costs $1000, and in a
couple of years it is expected to cost $100. This has spawned multiple new
industries that face serious computational challenges due to the size and
complexity of the data and associated algorithms. Solvuu addresses the full
spectrum of computational needs of this important market. We have great
investors and partnerships, and are now building a great engineering team.
Please join us. Solvuu is headquartered in New York City and also has an office
in Silicon Valley.
========================================================================
4) Ocaml 4.04.1 released
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00054.html>
------------------------------------------------------------------------
** Damien Doligez announced:
We have the pleasure of announcing the release of OCaml version 4.04.1,
dedicated to the memory of Emmy Noether on the anniversary of her death.
This is a bug-fix release, see the list of changes below.
It is available as a bunch of OPAM switch and as a source
download in the following locations:
<https://github.com/ocaml/ocaml/archive/4.04.1.tar.gz>
<https://caml.inria.fr/pub/distrib/ocaml-4.04/>
Happy hacking,
-- Damien Doligez for the OCaml team.
OCaml 4.04.1 (14 Apr 2017):
---------------------------
### Code generation and optimizations:
- PR#7501, GPR#1089: Consider arrays of length zero as constants
when using Flambda.
(Pierre Chambart, review by Mark Shinwell and Leo White)
### Standard library:
- PR#7403, GPR#894: fix a bug in Set.map as introduced in 4.04.0
(Gabriel Scherer, report by Thomas Leonard)
### Tools:
- PR#7411: ocamldoc, avoid nested <pre> tags in module description.
(Florian Angeletti, report by user 'kosik')
- PR#7488: ocamldoc, wrong Latex output for variant types
with constructors without arguments.
(Florian Angeletti, report by Xavier Leroy)
### Build system:
- PR#7373, GPR#1023: New flexlink target in Makefile.nt to bootstrap the
flexlink binary only, rather than the flexlink binary and the FlexDLL C
objects.
(David Allsopp)
### Bug fixes
- PR#7369: Str.regexp raises "Invalid_argument: index out of bounds"
(Damien Doligez, report by John Whitington)
- PR#7373, GPR#1023: Fix ocamlmklib with bootstrapped FlexDLL. Bootstrapped
FlexDLL objects are now installed to a subdirectory flexdll of the Standard
Library which allows the compilers to pick them up explicitly and also
ocamlmklib to include them without unnecessarily adding the entire Standard
Library.
(David Allsopp)
- PR#7385, GPR#1057: fix incorrect timestamps returned by Unix.stat on Windows
when either TZ is set or system date is in DST.
(David Allsopp, report and initial fix by Nicolás Ojeda Bär, review and
superior implementation suggestion by Xavier Leroy)
- PR#7405, GPR#903: s390x: Fix address of caml_raise_exn in native dynlink modules
(Richard Jones, review by Xavier Leroy)
- PR#7417, GPR#930: ensure 16 byte stack alignment inside caml_allocN on x86-64
for ocaml build with WITH_FRAME_POINTERS defined
(Christoph Cullmann)
- PR#7456, GPR#1092: fix slow compilation on source files containing a lot
of similar debugging information location entries
(Mark Shinwell)
- PR#7457: a case of double free in the systhreads library (POSIX implementation)
(Xavier Leroy, report by Chet Murthy)
- PR#7460, GPR#1011: catch uncaught exception when unknown files are passed
as argument (regression in 4.04.0)
(Bernhard Schommer, review by Florian Angeletti and Gabriel Scherer,
report by Stephen Dolan)
- PR#7505: Memory cannot be released after calling
Bigarray.Genarray.change_layout.
(Damien Doligez and Xavier Leroy, report by Liang Wang)
- GPR#912: Fix segfault in Unix.create_process on Windows caused by wrong header
configuration.
(David Allsopp)
- GPR#980: add dynlink options to ocamlbytecomp.cmxa to allow ocamlopt.opt
to load plugins. See <http://github.com/OCamlPro/ocamlc-plugins> for examples.
(Fabrice Le Fessant, review by David Allsopp)
- GPR#992: caml-types.el: Fix missing format argument, so that it can show kind
of call at point correctly.
(Chunhui He)
- GPR#1043: Allow Windows CRLF line-endings in ocamlyacc on Unix and Cygwin.
(David Allsopp, review by Damien Doligez and Xavier Leroy)
- GPR#1072: Fix segfault in Sys.runtime_parameters when exception backtraces
are enabled.
(Olivier Andrieu)
========================================================================
5) release of batteries-2.6.0
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00071.html>
------------------------------------------------------------------------
** Francois Berenger announced:
We are pleased to announce the 2.6.0 release of
OCaml batteries-included.
Batteries Included is a community-maintained standard library
extension, with a focus on performance, stability and compatibility.
Bug reports, pull requests and user feedback are warmly welcome, see the
project page at
<https://github.com/ocaml-batteries-team/batteries-included/>
The library's API documentation can be found at:
<http://ocaml-batteries-team.github.io/batteries-included/hdoc2/>
Batteries 2.6.0 is a minor release, compatible with OCaml 4.04.0.
As usual, Batteries 2.6.0 is compatible with older OCaml releases as well (until
OCaml-3.12.1), and provides back-ported
versions of most standard library functions made available recently.
After an 'opam update' your will be able to do an
'opam upgrade batteries' an enjoy this new release.
Many thanks to the contributors for this release:
Florian Angeletti
Francois Berenger
Michael Färber
Oscar Gauthier
Ifaz Kabir
Johannes Kloos
Gabriel Scherer
Thibault Suzanne
Detailed Changelog v2.6.0 (minor release)
added BatList.favg and faster BatList.fsum
#746
(Gabriel Scherer, Francois Berenger)
install .cmt and .cmti files
#740
(Francois Berenger, Gabriel Scherer)
BatMap: added find_default
#730
(Francois Berenger)
added scripts/test_install.sh
#743
(Francois Berenger)
BatHashtbl: added {to|of}_list, bindings
#728
(Francois Berenger, Thibault Suzanne)
added {BatList|BatArray}.shuffle
#702, #707
(Francois Berenger, Gabriel Scherer)
Clarification and improvements to the documentation
#682, #685, #693
(Florian Angeletti, Johannes Kloos, Michael Färber)
make LazyList.split_at lazy:
split_at : int -> 'a t -> 'a t * 'a t
would previously eagerly force the prefix of the list
and only be lazy in its second returned value.
#694
(Michael Färber, Gabriel Scherer, Thibault Suzanne)
Add List.{map2i,iter2i}
#696
(Thibault Suzanne)
Added Result.{map,map_both}
#705
(Ifaz Kabir)
Add {BatSet,BatMap}.{Int,Int32,Int64,Nativeint,Float,Char,String} as
common instantions of the respective Make functor.
#709, #712
(Thibault Suzanne, Francois Berenger)
BatString: add chop : ?l:int -> ?r:int -> string -> string
#714, #716
(Gabriel Scherer, request by Francois Berenger)
BatSet: make to_array allocate the resulting array at first
instead of using Dynarray (faster, uses less memory).
#724
(Thibault Suzanne)
BatList: add fold_left_map:
('a -> 'b -> 'a * 'c) -> 'a -> 'b list -> 'a * 'c list
#734
(Thibault Suzanne, review by Gabriel Scherer,
request by Oscar Gauthier)
add BatList.frange :
float -> [< `To | `Downto ] -> float -> int -> float list
frange 0. `To 1. 3 is [0.; 0.5; 1.].
#745
(Francois Berenger)
========================================================================
6) New release of Menhir (20170418)
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00075.html>
------------------------------------------------------------------------
** François Pottier announced:
It is my pleasure to announce a new release of Menhir,
which is available as of now via opam.
opam update && opam install menhir
The main changes are as follows:
- Changed Menhir's license from QPL to GPLv2. MenhirLib remains under LGPLv2,
with a linking exception.
- Moved the repository to gitlab.inria.fr, where it is public.
- Many additions to the incremental API, suggested by Frédéric Bour.
- A new library, MenhirSdk, allows external tools to get access to a
description of the grammar and automaton. This was also proposed
by Frédéric Bour. This change and the previous one, together, allow
error recovery strategies to be precomputed and implemented.
For more details, see the change log:
<https://gitlab.inria.fr/fpottier/menhir/blob/master/CHANGES.md>
========================================================================
7) Lwt 3.0.0 ? monadic promises and concurrent I/O
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00078.html>
------------------------------------------------------------------------
** Anton Bachin announced:
We are pleased to announce release 3.0.0 of Lwt, the concurrent
programming/promise library.
<https://github.com/ocsigen/lwt>
This release makes some minor breaking improvements to the Lwt API,
which were previously announced in release 2.7.0. You can see the
changelog here:
<https://github.com/ocsigen/lwt/releases/tag/3.0.0>
The non-breaking changes made to date are separated out into a preceding
Lwt 2.7.1, also released recently. Most notable are compatibility with
OCaml 4.05 and the official announcement of Lwt_result:
<https://github.com/ocsigen/lwt/releases/tag/2.7.1>
Release 3.0.0 completes the first test of Lwt's "soft" breakage
cycle [1]: Lwt warns users about upcoming breakage, provides simple
upgrade paths, and gives time to (optionally) adapt before the breakage
actually occurs. Simultaneously, users are invited to visit the Lwt
repository and object to any planned breaking change, or otherwise
contribute their opinions and expertise.
We hope that, going forward, this will give us the flexibility to fix
crufty parts of Lwt in a consensual fashion, without causing unjustified
headaches and surprises. Of course, we prefer to avoid breakage as much
as possible ? but, here and there, some things just need to be broken.
3.0.0 factors some of Lwt's optional dependencies fully out into their
own packages [2]. This process will likely continue with factoring out
the Camlp4 extension and the PPX [3]. We are also eyeing the Lwt Unix
bindings, though this requires more consideration.
On the subject of Unix, we are also considering some kind of "merger,"
literal or not, [4] between Lwt and uwt [5], the Lwt-aware binding to
libuv [6]. A combination of a libuv binding and prospective bindings to
Node.js [7] might be the best way to create portable, maintainable I/O
bindings at once for Unix-like operating systems, Windows, and Node.
This work, however, is in an absolutely embryonic stage, and we are not
sure how or where it might go.
Though not immediately relevant to users, work continues on reducing the
internal technical debt of Lwt. We hope this makes contributing to Lwt
easier in the future ? that Lwt will not be a forbidding code base.
This should help everyone in the longer term, and it goes hand-in-hand
with the slow writing of the new manual. It seems writing tests, and
refactoring Lwt in places, are necessary to gain the kind of
understanding needed to write a good, thorough manual in the first
place.
The Lwt project welcomes new co-maintainers: Mauricio Fernandez (@mfp)
and Simon Cruanes (@c-cube). Their fresh perspectives and expertise,
both general and specialized, already help the quality of Lwt greatly.
Happy concurrent programming,
Anton Bachin
[1]: <https://github.com/ocsigen/lwt/issues/293>
[2]: <https://github.com/ocsigen/lwt/issues/41>
[3]: <https://github.com/ocsigen/lwt/issues/338>
[4]: <https://github.com/ocsigen/lwt/issues/328>
[5]: <https://github.com/fdopen/uwt>
[6]: <http://libuv.org/>
[7]: <https://github.com/ocsigen/lwt/issues/270>
========================================================================
8) PPX is harmful to our community in the long term
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00085.html>
------------------------------------------------------------------------
** Hongbo Zhang said:
Given that bitten by PPX from time to time, finally, I think it is a time to
spend two hours sharing my experience with PPX and why you(the OCaml library
developer) should avoid PPX as much as you can.
Here is a story I just experienced this morning, I tried to install a package
from opam, and it complained my compiler is too old - 4.02.3, to be honest,
4.02.3 is still a pretty modern OCaml compiler, even debian stable still stays
on 4.01. Anyway, I switched to 4.04.1, after half an hour, it failed to compile
again, complaning about some ppx error message. This is not my first time
experience, and finally it made me to write an essay about why PPX is harmful.
PPX is a compiler plugin, it imposes a very large compiler surface API to your
library, and we don't have any backward compatibility guarantee from the
compiler, which means your library will only work against a specific compiler.
Even worse, OCaml is an elegant but small community, we don't have too many
maintainers for a library, if you have a library which relies on PPX (the
dependency chain could be really really huge, for example, ppx_metaquot depends
on typing environment, you can find lots of stories about node_modules in Node
community), it will probably not work against next version of OCaml compiler,
and it will be a huge maintenance overhead for other people to pick it up.
OCaml is already a very expressive language, probably more expressive than any
other mainstream language, (Go, Java, C/C++, etc), it is fine to write some
boilerplate code, or we can cut PPX as a dev dependency, after your PPXed your
code, check in the generated source code(via -dsource), so it will not bring
dependency to end users. There are some valid use cases of PPX, for example, in
BuckleScript or JS_of_OCaml, we want to customize OCaml language a bit for
external FFI, or if you have a very large team, and committed effort to maintain
your PPX.
Happy hacking in OCaml without PPX, Thanks -- Hongbo
** Yotam Barnoy then said:
My 2 cents: I personally think we did PPX wrong. PPX should have used
the syntax as its starting point for full backwards compatibility.
Currently, the PPX cycle is
OCaml: { syntax -> AST -> serialized AST } -> PPX: {serialized AST ->
AST -> PPX modification -> serialized AST} -> OCaml: {serialized AST
-> AST -> ... }
Exposing the AST is the cause of the problem you mention. If instead,
every PPX extension had a particular OCaml compiler's syntax parser
and syntax printer integrated into it, and the PPX cycle was:
PPX: { syntax -> AST -> PPX modification -> syntax } -> compiler: {
syntax -> AST -> ...}
We would have far fewer issues with PPX plugins, since they would be
as backwards-compatible as the syntax.
I think this mistake happened because everyone was trying to move away
from camlp4's complexity, and we didn't notice that the problem with
camlp4 wasn't the approach, but rather the fact that it wasn't making
use of the same code as the compiler and therefore required its own
heavy learning-curve and parallel maintenance to keep up with the
compiler. To be fair though, camlp4 came before the age of OCaml on
github, opam, and the associated easy code/library sharing.
The only issue I can see with this idea of improving PPX is that the
PPX-generated syntax wouldn't have the original source locations. We'd
need an annotation that indicated the original source locations
(perhaps row and column offsets) when a PPX translated to modified
syntax and printed it out, so that the compiler's errors would have
proper locations relative to the original source.
** Gerd Stolpmann then replied:
So far I understand, with "syntax" you really mean syntax-as-string.
I think most often the AST changes by adding more fields or more AST nodes.
Wouldn't the situation already improve a lot if we switched to record variants
for the AST types? (Besides that the compiler would get way more readable.) New
fields wouldn't be a big problem anymore because they are looked up by name and
not by position.
** Alain Frisch also replied:
I think
<https://github.com/let-def/ocaml-migrate-parsetree>
is a much stronger approach. If I understand correctly, Jane Street moved from
using a migration system based on concrete syntax to using this new project.
In your suggested approach, imagine you have a PPX processor written for OCaml
4.04. It assumes that the Parsetree it works on is the one of 4.04. Sure, you
can compile this PPX processor (+ embedded parser/printer) into a stand-alone
executable, using OCaml 4.04, and then apply it as a preprocessor called from
OCaml 4.05. But this is very impractical: users would need to install OCaml
4.04 just to produce the PPX executable. Moreover, you loose the ability to
combine multiple rewritings in a single process, and you have to pay the price
of multiple parsing/printing/processes. On top of that:
(i) you put in the critical loop "pprintast.ml", which has always been more or
less buggy;
(ii) there is no hope that an "old PPX" applies to source code using newest
syntactic features;
(iii) as you mention, locations would need to be added for each node in the
AST, which makes the parsing/printing even slower; moreover, it is not
technically straightforward to do so, since many places in the AST contains
locations but do not support attaching attributes;
(iv) we loose the ability to change the concrete syntax of OCaml, either to
use alternative syntaxes such as Reason, or to remove, at some point, weird
corner cases in the current syntax.
With ocaml-migrate-parsetree, you can still compile your PPX written for 4.04
with newer versions of OCaml. And it would even be possible (I don't know if
this is already the case) to apply it to source code using newer syntactic
features, as long as the rewriting done by the PPX doesn't interact with those
features. (This could be achieved by turning new syntactic features into
attributes/extension nodes when mapping to the older AST; and then recognizing
these forms and reconstitute the correct new AST forms when mapping back to the
new version.)
** Jeremie Dimino then added:
Yes, we are now using ocaml-migrate-parsetree at Jane Street. I think that with
this library the versioning story is much better. We are heavy user of ppx
rewriters and all of the code we release now builds with OCaml 4.03 to 4.06
without problems.
Initially we considered using the concrete syntax to solve the versioning
problem and we have a solution that should work in theory. Although it's not
great when there is no source file, such as in the toplevel. The method we
considered is described in [1]. Switching to ocaml-migrate-parsetree was easier
since we didn't have to change anything to the way things worked, just port the
code.
Regarding the idea of cutting down the dependency for release tarballs by
including the generated code, while this is an interesting idea, there are a lot
of small annoying problems that makes this technique hard in practice. The two
main problems are:
1. it doesn't work for .ml files that are generated. Basically all the code you
generate with custom code generators as to be ppx free. It is fine however for
pure generators, since you can just embed the generated code
2. it doesn't work if you use conditional compilation. Conditional compilation
is not great in general, but it is a lot of work to completely get rid of it
However, one thing that we kept from these experiments is the idea to use ppx in
the same way that expectation tests work. This idea is described in [1] and we
use it for the Base library [2]. Additionally it is a good testing/debugging
tool. It is a viable solution if all you need is [@@deriving] plugins and don't
want to depend on ppx.
The idea is to let the ppx rewriter insert the code generated by [@@deriving]
plugins in the source code:
type t = A | B [@@deriving_inline sexp_of]
let sexp_of_t = function
| A -> Sexp.Atom "A"
| B -> Sexp.Atom "B"
[@@@end_of_derived_code]
The code builds without ppx and you still don't have to write the boilerplate
yourself, you let the ppx tool do it for you.
[1] <https://blogs.janestreet.com/an-solution-to-the-ppx-versioning-problem/>
[2] <https://github.com/janestreet/base>
** Yaron Minsky replied to the initial post:
I understand the frustration, but I think your conclusion is
misplaced. PPXs are massively helpful when building serious software.
Having automatic generation of pretty-printers, comparison functions,
hash functions, binary protocols, and the like is a huge win for both
programmer efficiency and correctness. The Haskell folk aren't wrong
to care about deriving, and the schemers aren't crazy to want their
macro systems.
In short, I think abandoning syntactic abstractions is madness.
I agree that the portability problems are serious and should be
addressed, but ocaml-migrate-parsetree seems like a solid step in the
right direction.
** Hongbo Zhang then said:
Yes, when you never depend on other people's PPX, it is perfectly fine to
provide a customized suite of PPX. Think about the software which only works
against 4.03, 4.04, this is equivalent to say that you release a c++ library
only works with gcc 7 while most enterprises are still using 4.8, nobody even
think it is a serious piece of software. It is a different story in Haskell
deriving or Scheme macro system, there is no issue that you software in use
today will be not compilable in the future.
** Fabrice Le Fessant then replied:
A lot of people use `autoconf` to generate `./configure` scripts, and the
standard practice is to keep the `./configure` script so that people don't need
to run `autoconf` to just compile and install the software. Maybe projects could
do the same with ppx, i.e. store pre-processed files in the project sources so
that the ppx would only be needed when the developer modifies the sources. For
example, there could be a `_ppx` directory, where pre-processed files would be
stored under the hash of a combination of their original source code and the
`-ppx` arguments. The compiler (or the build system) would use these files when
available instead of calling the ppx. That might reduce the problem at least for
`opam`, since users are not supposed to edit the packages when installing them.
** Emilio Jesús Gallego Arias also replied to the initial post:
indeed I think this problem is real as I have been trying to design a
plan for Coq 8.8 (expected Q1 2018) to depend on PPX, and indeed it has
not been easy to come up with something that wouldn't be turned down by
the developers due to compatibility concerns.
It is great to hear that ocaml-migrate-parsetree helps and that the
situation is improving, but maybe the biggest concern would Coq adopt
that solution, is how fast would it become "obsolete", to be replaced by
a new one.
From my attendance to the Coq WG I got the personal feeling that there
was some amount of uncertainty about what the OCaml roadmap regarding
certain features is. This in turn difficults the elaboration of Coq's
own roadmap.
========================================================================
9) BuckleScript 1.7
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00096.html>
------------------------------------------------------------------------
** Hongbo Zhang announced:
BuckleScript is an optimizing compiler for OCaml to generate readable
JavaScript, it is open sourced by Bloomberg [1].
Major changes are listed here:
<https://github.com/bloomberg/bucklescript/blob/master/site/docsource/Release.1.7.0.adoc>
Documentation is available here: <http://bloomberg.github.io/bucklescript/Manual.html>
To install:
npm install -g bs-platform
Happy hacking in OCaml! -- Hongbo
[1]: <https://github.com/bloomberg/bucklescript/>
========================================================================
10) CUFP 2017 Call for Tutorials
Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2017-04/msg00108.html>
------------------------------------------------------------------------
** Runhang Li announced:
Call for tutorials
Commercial Users of Functional Programming (CUFP) 2017
September 7th-9th, 2017, Oxford, United Kingdom
Co-located with International Conference on Functional Programming (ICFP)
Dear fellow camels,
Commercial Users of Functional Programming (CUFP) 2017 is now seeking
tutorials proposals.
Co-located with International Conference on Functional Programming (ICFP),
Commercial Users of Functional Programming (CUFP) will take place in Oxford, U.K.
from 7th to 9th of September, 2017. CUFP is devoted to showcase the state of
the art of functional programming in industrial settings.
We are looking for tutors who would like to host half-day tutorial sessions
of the following topics:
* Introductions to functional programming languages, e.g., Haskell, OCaml,
Scala, F#, Scheme, Erlang, Clojure.
* Advanced programming languages, concepts, or applications, e.g., Agda, Idris,
F*, Coq, Eff.
* Applications of functional languages in particular areas, including web,
high-performance computing, and finance.
* Tools and techniques supporting state of the art functional programming, e.g.,
ReasonML, TypeScript, Elm, QuickCheck, FlowType.
* Theory. Type theory, category theory, abstract algebra, ongoing or new
research, or anything useful or interesting to functional programmers.
**Proposal submission deadline is May 25th**
Details can be found at: <http://cufp.org/2017/call-for-tutorials.html>
========================================================================
11) 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.
- generalize -dtimings to show allocation, top heap size
<https://github.com/ocaml/ocaml/pull/1152>
- Spellchecker hints and type-directed disambiguation for extensible variants
<https://github.com/ocaml/ocaml/pull/1154>
========================================================================
12) 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: Front-end Developer at issuu in Copenhagen
<http://jobs.github.com/positions/9c9c5cac-28e3-11e7-8515-f5b67b252bbb>
Seventeenth OCaml compiler hacking evening at Pembroke
<http://ocamllabs.github.com/compiler-hacking/2017/04/18/seventeenth-compiler-hacking-may>
News about Tyre | Drup's thingies
<https://drup.github.io/2017/04/17/tyre-news/>
EzSudoku
<http://www.ocamlpro.com/2017/04/11/ezsudoku/>
========================================================================
Old cwn
------------------------------------------------------------------------
If you happen to miss a CWN, you can send me a message
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
========================================================================
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-03: 407.18, 2016-03: 404.83
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20170425/55bd73e7/attachment-0001.pgp>
More information about the caml-news-weekly
mailing list