[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 12607 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of June 09 to 16,
2020.

Table of Contents
─────────────────

First release of monolith
Sylvain Conchon joined OCamlPro's team
First release of streaming
Senior software engineer at Asemio in Tulsa, OK
Other OCaml News
Old CWN


First release of monolith
═════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/ann-first-release-of-monolith/5946/1]


François Pottier announced
──────────────────────────

  It is my pleasure to announce the first release of Monolith.

  Monolith offers facilities for testing an OCaml library (for instance,
  a data structure implementation) by comparing it against a reference
  implementation.  It uses a form of black-box testing, and relies on
  `afl-fuzz' for efficiency.

  The user must describe what types and operations the library
  provides. Under the best circumstances, this requires 2-3 lines of
  code per type or operation.  The user must also provide a reference
  implementation of the library.

  Then, like a monkey typing on a keyboard, Monolith attempts to
  exercise the library in every possible way, in the hope of discovering
  a scenario where the library behaves incorrectly. If such a scenario
  is discovered, it is printed in the form of an OCaml program, so as to
  help the user reproduce the problem.

  At this time, a tutorial is not yet available. There is however an API
  documentation and a number of demos.

  Repository: [https://gitlab.inria.fr/fpottier/monolith]

  API Documentation:
    [http://cambium.inria.fr/~fpottier/monolith/doc/monolith/Monolith/index.html]

  Installation:
  ┌────
  │ opam update
  │ opam install monolith
  └────


Sylvain Conchon joined OCamlPro's team
══════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/sylvain-conchon-joined-ocamlpros-team/5956/1]


OCamlPro announced
──────────────────

  Sylvain Conchon joined OCamlPro's team as Formal Methods CSO. He
  created Alt-Ergo and has been teaching OCaml in universities for about
  20 years. He shares thoughts on interactions between industry and
  research labs, and his vision of Formal methods and OCaml as language
  for the industry. Read his interview on our blog:
  [https://www.ocamlpro.com/2020/06/05/interview-sylvain-conchon-cso-on-formal-methods/]


First release of streaming
══════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/ann-first-release-of-streaming/5961/1]


Rizo announced
──────────────

  It is my pleasure to announce the first public release of `streaming'
  – a library for building efficient, incremental data processing
  pipelines that compose and don't leak resources.

  I built streaming as a result of many experiments with different
  streaming and iteration models for OCaml. There are multiple packages
  on OPAM that share some of the goals of `streaming' (we even have
  `Stdlib.Seq' now!), but none of them combine (1) excellent
  performance, (2) safe resource handling and (3) pure functional style
  for combinators.  Streaming solves these problems by implementing
  three basic and independent models: _sources_, _sinks_ and _flows_ –
  they represents different parts of the pipeline that correspond to
  producing, consuming and transforming elements.  These models can be
  defined and composed independently to produce reusable "streaming
  blocks".

  The library defines a central `Stream' model that relies on sources,
  sinks and flows. This model is a push-based iterator with performance
  characteristics similar to the `iter' iterator, which has type `('a ->
  unit) -> unit', and is known for being very efficient. But unlike
  `iter', it has a pure functional core (no need to use mutable state
  and exceptions for flow control!) and can handle resource allocation
  and clean up in a lazy and deterministic way. All of this while having
  a slightly better performance for common stream operations.

  For those who are curious about the performance characteristics of
  `streaming' and other models, I created a dedicated repository for
  stream benchmarks: [https://github.com/rizo/streams-bench]. In
  particular, it includes a few simple benchmarks for `Gen',
  `Base.Sequence', `Stdlib.Seq', `Iter', `Streaming.Stream' and
  `Streaming.Source'.

  The library should soon be published on opam. In the meantime, I
  invite you to read the docs and explore the code:

  • Library documentation: [https://odis-labs.github.io/streaming]
  • Github project: [https://github.com/odis-labs/streaming]


Guillaume Bury askec
────────────────────

  That's great ! From the benchmarks, it looks like you hit a really
  good implementation !

  I've looked (maybe a bit fast) at the API documentation, and it is
  admittedly a bit outside the scope of streams/iterators, but I was
  wondering if there was some proper way to:
  • connect a sink to a source to create some loop
  • have some kind of fixpoint on streams

  I guess it would always be possible to use some references and/or some
  complex functions to encode these into the provided API, but I was
  wondering if there was a clean way to do it.

  For a bit of context and explanation, what I have in mind is the case
  of a program (let's say a type-checker or something close to the idea)
  with a *persistent state*, that should operate over a stream of
  inputs, which are top-level phrases, and produce some outputs, for
  instance print some result for each correctly type-checked statement
  (and an error otherwise).  The type-checker would basically be a
  function of type `(`input * `state) -> (`output * `state)', and
  starting from an initial state, it would process an input element
  (giving the output to some sink), and then the next input element
  would be processed with the state that was reached after processing
  the previous element: the state would reach the sink of the flow, and
  then be inserted back into the source.  Separately, imagine the
  language being type-checked has a notion of include, then one of the
  step of the flow would be to expand each include into a stream of
  inputs/phrases, but each of the phrases in this stream would need to
  be expanded, so a simple `flat_map~/~flatten' is not enough.

  I already have a custom implementation that handle these features, but
  I was wondering whether I could use `streaming' to handle most of the
  code linking all of the steps, ^^


Rizo replied
────────────

        if there was some proper way to:
        • connect a sink to a source to create some loop
        • have some kind of fixpoint on streams

  Regarding the first point: yes! That's exactly the point of the
  `Stream' module. You see, sources are pull-based abstractions, while
  sinks are push-based. Source's type essentially says something like
  _"I might give you some data, if you ask"_, while sink's type is the
  opposite _"I might take some data, if you give it to me"_. They are
  completely and intentionally decoupled; it is Stream's role to drive
  the computation by pulling data from sources and pushing it into
  sinks. So the easiest way to connect them is:

  ┌────
  │ Stream.(from srouce |> into sink)
  └────

  Of course, that's not very useful per se, but it illustrates my
  point. Take a look at the [`Stream.from'] code to see the
  implementation of the loop you're asking for. It does some extra work
  to ensure that resources are correctly handled, but it should be clear
  what the loop is doing.

  The stream types in the library are currently abstract because I
  didn't want to commit to a particular representation just yet. If this
  is a problem for your use case, let me know, I'll expose them in a
  `Private' module.

  Regarding the second point: I'm not sure what you mean in practice by
  "fixpoint on streams". I guess the one thing that could help implement
  something like that is the [`Stream.run'] function. It allows you to
  continue reading elements from a source even after a sink is filled by
  returning a leftover stream.  This stream can be used with
  `Stream.run' repeatedly.

  Alternatively there's also [`Flow.through'], which consumes input
  trying to fill sinks repeatedly and produces their aggregated values
  as a stream. Super useful for things like streaming parsing. Might
  even help with your use-case for top-level phrases.

  On a more general note though, the type `('input * 'state) -> ('output
  * 'state)' looks a lot like a [mealy machine]. `Streaming.Sink' is a
  [moore machine], which is slightly less general because the output
  values do not depend on input values, only on the state.

  I thought about exposing different kinds of sinks in streaming, but
  wanted to make sure that the common use cases are covered first. I'll
  keep your case in mind for future versions of the library.


[`Stream.from']
https://github.com/odis-labs/streaming/blob/0.8.0/lib/Stream.ml#L42

[`Stream.run']
https://odis-labs.github.io/streaming/streaming/Streaming/Stream/index.html#val-run

[`Flow.through']
https://odis-labs.github.io/streaming/streaming/Streaming/Flow/index.html#val-through

[mealy machine] https://en.wikipedia.org/wiki/Mealy_machine

[moore machine] https://en.wikipedia.org/wiki/Moore_machine


Senior software engineer at Asemio in Tulsa, OK
═══════════════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/senior-software-engineer-at-asemio-in-tulsa-ok/5979/1]


Simon Grondin announced
───────────────────────

  We are Asemio and our team of data scientists, software engineers,
  architects, and management consultants are working together to achieve
  a nationwide data ecosystem for social good.

  You’ll be working on the Asemio Community Integration Platform. It
  features state-of-the-art privacy-preserving, pre-processing and
  pipeline management, as well as record linkage technology.

  The back end is written in OCaml. The front end is compiled from OCaml
  to JavaScript and uses a modern MVC framework.  The work you’ll be
  doing will touch numerous technical disciplines, including
  cryptography, distributed systems, language design and implementation,
  data analytics, and data visualizations.

  We prefer candidates willing to relocate, but we could make an
  exception for an exceptional candidate.

  For more information or to apply, please refer to our SE listing:
  [https://stackoverflow.com/jobs/401383/ocaml-senior-software-engineer-asemio]


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Frama-C 21.0 (Scandium) is out. Download it here.]
  • [Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]


[OCaml Planet] http://ocaml.org/community/planet/

[Frama-C 21.0 (Scandium) is out. Download it here.]
http://frama-c.com/index.html

[Every proof assistant: Epigram 2 - Autopsy, Obituary, Apology]
http://math.andrej.com/2020/06/09/epigram-2-autopsy-obituary-apology/


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]


[send me a message] mailto:alan.schmitt@polytechnique.org

[the archive] http://alan.petitepomme.net/cwn/

[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss

[online] http://lists.idyll.org/listinfo/caml-news-weekly/

[Alan Schmitt] http://alan.petitepomme.net/


[-- Attachment #2.2: Type: text/html, Size: 25107 bytes --]