caml-list - the Caml user's mailing list
 help / color / Atom feed
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-14 14:16 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-01-14 14:16 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1: Type: text/plain, Size: 24944 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of January 07 to 14,
2020.

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

Calling a single function on every member of a GADT?
OCamlPro's opam cheat sheet, with a new theme!
OCaml 4.10.0, first beta
Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
Release of naboris 0.1.0 a simple http server
esy@0.6.0 release
Old CWN


Calling a single function on every member of a GADT?
════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00007.html>


Ivan Gotovchits asked
─────────────────────

  I'm basically trying to do the equivalent of this simple `fold'
  function:

  ┌────
  │ module Simple =
  │ struct
  │   type term =
  │      | Int of int
  │      | Add
  │      | App of term * term
  │ 
  │   let rec fold i f = function
  │     | Int _ as t -> f i t
  │     | Add -> f i Add
  │     | App (x, y) as t -> f (fold (fold i f x) f y) t
  │ end
  └────

  … but using a GADT:

  ┌────
  │ module Gadt =
  │ struct
  │   type _ term =
  │      | Int : int -> int term
  │      | Add : (int -> int -> int) term
  │      | App : ('b -> 'a) term * 'b term -> 'a term
  │ 
  │   let rec fold : type a. 'r -> ('r -> _ term -> 'r) -> 'r = fun i f -> function
  │     | Int _ as t -> f i t
  │     | Add -> f i Add
  │ (*
  │      ^ Error: This pattern matches values of type (int -> int -> int) term
  │ 	but a pattern was expected which matches values of type int term
  │ 	Type int -> int -> int is not compatible with type int
  │ *)
  │     | App (x, y) as t -> f (fold (fold i f x) f y) t
  │ end
  └────

  I've tried other variants of the syntax and got many encouragements
  but no green flag from the type-checker.  Why is the compiler
  expecting an int term in there? I though the whole point of the `type
  a. ...' syntax was to allow the matched type to vary from one pattern
  to the next?  Is there a way to do this?


Ivan Gotovchits replied
───────────────────────

  It is the limitation of the let-bound polymorphism. A parameter of a
  function is monomorphic in its body. The classical example doesn't
  even reference any GADT,

  ┌────
  │ let example f  = f "hello", f 42
  └────

  It won't compile even though we can provide a polymorphic function
  that can applied both to integers and to strings, e.g., `exampe (fun x
  -> x)' should be possible, but not, because of the let-bounded
  polymorphism. There are a few solutions available in OCaml, the
  simplest is to use records, e.g.,

  ┌────
  │ type app = {apply : 'a. 'a -> 'a}
  │ 
  │ let example {apply} = apply "hello", apply 42;;
  │ 
  │ val example : app -> string * int = <fun>
  └────

  Now we have `app' that is polymorphic.  In your case, I would define a
  visitor type, e.g.,

  ┌────
  │ type 'r visitor = {visit : 'a. 'a term -> 'r -> 'r}
  │ 
  │ let rec fold : type a. 'r -> 'r visitor -> a term -> 'r =
  │   fun i f t -> match t with
  │     | Int _ as t -> f.visit i t
  │     | Add as t -> f.visit i t
  │     | App (x,y) as t ->
  │ 	let i = fold i f x in
  │ 	let i = fold i f y in
  │ 	f.visit i t
  └────


Jacques Garrigue also replied
─────────────────────────────

  Actually, this is a rare case where using a polymorphic method may be
  handy too:

  ┌────
  │ let rec fold : type a r. r -> <v : 'b. r -> 'b term -> r> -> a term -> r =
  │      fun i f -> function
  │      | Int _ as t -> f#v i t
  │      | Add -> f#v i Add
  │      | App (x, y) as t -> f#v (fold (fold i f x) f y) t
  │ 
  │ let v =
  │    object method v : type a. _ -> a Gadt.term -> _ =
  │      fun x -> function
  │        | Int n -> x+n
  │        | Add -> x+1
  │        | App _ -> x+2
  │    end
  │ 
  │ let r = Gadt.fold 0 v (App (App (Add, Int 3), Int 5))
  └────

  The point being that to match on a Gadt you will anyway need to use
  the (type a) construct to allow refinement.


rixed asked and Ivan Gotovchits replied
───────────────────────────────────────

        So there is no lighter syntax to specify that `f' should
        accept any member of a GADT than the syntax to specify
        that `f' should accept any type at all?

  Only three methods of introducing rank-2 polymorphism are known to me:
  1. records
  2. objects
  3. first-class modules

  Jacques has demonstrated the solution with objects, which might be a
  little bit more lightweight, at least as you don't need to define a
  new data type beforehand. But the invocation is more verbose and
  requires an annotation from the caller side, which could be
  confusing. The third solution relies on first-class modules and is
  even more verbose, at least on the definition side. Just for the sake
  of completeness,

  ┌────
  │   module type Visitor = sig
  │     type t
  │     val term : t -> 'a term -> t
  │   end
  │ 
  │   let rec fold : type a r. r -> (module Visitor with type t = r) -> a term
  │ -> r =
  │     fun i ((module Visit) as f) t -> match t with
  │       | Int _ as t -> Visit.term i t
  │       | Add as t -> Visit.term i t
  │       | App (x,y) as t ->
  │ 	  let i = fold i f x in
  │ 	  let i = fold i f y in
  │ 	  Visit.term i t
  │ 
  │   let s = fold 0 (module struct
  │       type t = int
  │       let term x _ = x + 1
  │     end)
  └────

  And again, it is not about GADT. GADT act as a red herring here. As
  I've demonstrated earlier, using a simple pair will suffice to display
  the limitation of the prenex polymorphism. Even no ADT is required,
  just apply one term to another two and you will get them unified,
  e.g.,

  ┌────
  │ let f g x y : unit = g x; g y
  └────

  will have type

  ┌────
  │ val f : ('a -> unit) -> 'a -> 'a -> unit
  └────

  because 'a is quantified on the scope of `f' not `g', in other words,
  it has type (not an OCaml syntax)

  ┌────
  │ val f : forall 'a. ('a -> unit) -> 'a -> 'a -> unit
  └────

  while we would like to have a type

  ┌────
  │ val f : forall 'b, 'c. (forall 'a. 'a -> unit) -> 'b -> 'c -> unit
  └────

  OCaml doesn't allow us to define types like `('a. 'a -> 'a)' and the
  reason is not that it is hard to extend the parser it is…

        I wonder, is this just a limitation of the OCaml parser or
        is there some deep reason for these work-around (like is
        the case, from my understanding, for the value
        restriction)?

  Yep, good catch! It is because of the impurity. Indeed, Haskell has
  the Rank2Types extension that lets us write types like `(forall a. a
  -> ()) -> b -> c -> ()', with no extra syntactic burden (modulo having
  to provide the type annotation). But functions in Haskell are pure,
  therefore it is possible. To make the story short and obvious, let me
  do a simple demonstration of how things can go wrong in a language
  with side-effects.  Let's go back to the simple example of pairs and
  the identity function.  Consider the following nasty identity
  function,

  ┌────
  │ let bad_id () =
  │   let cache = ref None in
  │   fun x -> match cache.contents with
  │     | None -> cache := Some x; x
  │     | Some cache -> cache
  └────

  It has type `unit -> 'a -> 'a' therefore, if we would have the rank-1
  polymorphism enabled for functions, we could apply it to the function

  ┌────
  │ let map2 : fun ('a. 'a -> 'a) -> 'b -> 'c -> 'b * 'c = fun f (x,y) -> f x, f y
  └────

  as

  ┌────
  │ let x,y : string * int = map2 (bad_id ()) "hello", 42
  └────

  and will get a segmentation fault, as `y' will now have type int but
  hold a string.

  And here comes the syntax as a savior as it lets us specify functions
  that are guaranteed to be syntactic values. Indeed, all three
  solutions syntactically guarantee that the provided argument is a
  function, not a closure. Indeed, let's introduce the universal
  identity via a record,

  ┌────
  │ type id = { f : 'a. 'a -> 'a}
  └────

  and we can see that our `bad_id' is not accepted due to the value
  restriction, while good_id, defined as,

  ┌────
  │ let good_id x = x
  └────

  is perfectly fine, e.g.,

  ┌────
  │ let id1 = {f = good_id} (*accepted *)
  │ let id2 = {f = bad_id}   (* rejected *)
  └────

  moreover, even a fine, but not syntactic, identity is also rejected

  ┌────
  │ let fine_id () x = x
  │ let id3 = {f = fine_id ()} (* rejected *)
  └────

  with the message

  ┌────
  │ This field value has type 'b -> 'b which is less general than 'a. 'a -> 'a
  └────

  The same is true with modules,

  ┌────
  │ module type Id = sig
  │   val f : 'a -> 'a
  │ end
  │ module Id1 : Id = struct let f = good_id end   (* accepted *)
  │ module Id2 : Id = struct let f = bad_id () end (* rejected *)
  │ module Id3 : Id = struct let f = fine_id () end (* rejected *)
  └────

  and with objects (left as an exercise).

  To summarize, in order to enable rank2 polymorphism we need a special
  kind of values to bear universal functions, as we can't rely on
  ordinary functions, which could be constructed using partial
  application. OCaml already had objects and records, which serve as a
  fine media for universally quantified functions. Later first class
  modules were introduced, which could also be used for the same
  purpose. Probably, one could devise a special syntax (or rely on the
  new attributes and extensions syntax, e.g., `map2 [%rank2 : fun x ->
  x] ("hello",42)' but probably this will lead to an unnecessary
  bloating of the language and the implementation, especially since we
  already have three solutions with a more or less tolerable syntax (and
  are in the base language, not an extension).  Besides, if we will use
  the `[@@unboxed]' annotation, or visitor will have the same
  representation as a function, e.g.,

  ┌────
  │ type 'r visitor = {visit : 'a. 'r -> 'a term -> 'r} [@@unboxed]
  │ let count x _ = x + 1
  │ let counter = {visit=count}
  └────

  and

  ┌────
  │ # Core_kernel.phys_same count counter;;
  │ - : bool = true
  └────

  Concerning rank-n polymorphism, in OCaml is is achieved using
  functors.  Yes, they are a little bit syntactically heavy and force us
  to write signatures, but this is necessary anyway as rank-n is
  undecidable (non-inferrable). Finally, as a real-world example [1] of
  rank-2 polymorphism consider the universal WAVL tree that is a binary
  tree with each element having a different type (aka heterogeneous
  map). We use it in BAP as a backing store. You might find a few tricks
  there, especially using continuation-passing in the recursive cases.

  Cheers, Ivan

  [1]:
  <https://github.com/BinaryAnalysisPlatform/bap/blob/b40689e636607b977758af048b79d65684ce48c3/lib/knowledge/bap_knowledge.ml#L847-L1693>


Malcolm Matalka asked and Ivan Gotovchits replied
─────────────────────────────────────────────────

        Why is type checking creating a record different than type
        checking a function argument?

        If we had the syntax (or something like it):

        let map2 : ('a. 'a -> 'a) -> ('b * 'c) -> ('b * 'c)

        Why would the type checker not be able to see that

        map2 good_id ("hi", 42)

        is valid but

        map2 (fine_id ()) ("hi", 32)

        is not, using the same logic that is verifying creating
        the "id" record is not valid?

  I believe it is possible, as it is possible in Haskell (with
  RankNTypes and ScopedTypeVariables). The main (theoretical) difference
  is that in OCaml we need to check whether an expression is expansive
  and use a specialized generalization in case if it is (for the relaxed
  value restriction). It will, however, complicate the type inference
  engine a lot, but most importantly, changing the typing rule of
  functions will have a tremendous impact on the language. So this would
  be a very impractical solution.  Especially, since we don't have the
  mechanism of language extensions, enabling RankNTypes will make a lot
  of programs untypeable, as they will now require type annotations
  (recall that RankN is undecidable in general).  It could probably be
  implemented as a compiler command line parameter, like `-rectypes' but
  this will be still quite impractical since more often code like `fun f
  -> f 1, f true' is a programmer error, rather than a true request for
  universal polymorphism (the same as with rectypes, recursive types a
  more often an error rather than a deliberate attempt). Therefore,
  enabling RankN(^1) polymorphism will type too many programs (not that
  it is unsound, just many programs won't have sense) at the cost of
  even more obscure type errors. On the other hand, we have three
  syntactic constructs that let us express non-prenex polymorphism of
  the necessary rank(^2) without breaking anything else. So it looks
  like a good deal - we can have rankN polymorphism and decidable type
  checker at the same time. Just think of polymorphic records/methods as
  an embedded DSL for rankN polymorphism.

  `==========' Footnotes:

  1) An important point, that I forgot to notice, is that enabling
     scoped
  type variables, will inevitably enable rankN polymorphism, e.g., since
  now any type could be a polytype, then suppose we have type
  `'a. ('b.'b -> 'a) -> 'a' could be instantiated to 'a = 'd. ('c. ->
  'd) -> 'd, so that our type is now `'d. ('b. 'b -> ('c. 'c -> 'd) ->
  'd) -> ('c. 'c -> 'd) -> 'd' which is now rank3. Therefore, enabling
  arbitrary quantification in the arrow type will lead to rankN and
  immediately make undecidable most of the type checker.

  1) We can craft arbitrary rank using records with universally
     quantified
  type variables, e.g., here is an example of rank3 polymorphism:

  ┌────
  │ type 'a rank1 = {f1 : 's. 's -> 'a}
  │ type 'a rank2 = {f2 : 'r. 'r -> 'a rank1}
  └────

  Indeed, `f2' has type `'a.('r. 'r -> ('s. 's -> 'a)'


OCamlPro's opam cheat sheet, with a new theme!
══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/rfc-ocamlpros-opam-cheat-sheet-with-a-new-theme/4689/3>


Thomas Blanc announced
──────────────────────

  The opam cheat-sheet is now published in its final form.

  You can get the [colored] and [black-and-white] versions from our
  website.

  Happy hacking!


[colored]
<http://www.ocamlpro.com/wp-content/uploads/2019/11/ocaml-opam.pdf>

[black-and-white]
<http://www.ocamlpro.com/wp-content/uploads/2020/01/ocaml-opam-bw.pdf>


OCaml 4.10.0, first beta
════════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-first-beta/4989/1>


octachron announced
───────────────────

  The release of OCaml 4.10.0 is approaching. We have published a first
  beta version to help you adapt your software to the new features ahead
  of the release.

  During our preliminary tests for this new beta, we discovered that the
  recent work towards a multicore-ready OCaml runtime introduced
  compatibility issues within some opam packages, that were tweaking the
  runtime internals.  Most of those opam packages have been fixed, or
  will be soon.  Nevertheless, if you are affected by such compatibility
  issue, please speak up.

  The source code is available at these addresses:

  <https://github.com/ocaml/ocaml/archive/4.10.0+beta1.tar.gz>
  <https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta1.tar.gz>

  The compiler can also be installed as an OPAM switch with one of the
  following commands.
  ┌────
  │ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  or
  ┌────
  │ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where you replace <VARIANT> with one of these:
  • afl
  • flambda
  • fp
  • fp+flambda

  We want to know about all bugs. Please report them here:

  <https://github.com/ocaml/ocaml/issues>

  Happy hacking.


Kate added
──────────

  For the people wanting to give OCaml 4.10.0beta1 a shot, here is an
  opam overlay which adds fixes to major packages for them to work with
  this beta: <https://github.com/kit-ty-kate/opam-alpha-repository>

  To use it, simple call:
  ┌────
  │ $ opam switch 4.10
  │ $ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
  └────

  Obviously, this repository should not be used in production and
  probably contains a few bugs, but at least it allows everyone to have
  almost as many packages available as with OCaml 4.09. Only 60ish
  packages are still not available, but apart from the notable exception
  of `merlin' all the essential packages and dependencies are there.

  This work has been part of the release-readyness effort founded by the
  OCaml Software Foundation as announced here:
  <https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>

  The rest of the effort is going to be put towards having `merlin'
  available for OCaml 4.10 and upstreaming all the fixes from
  opam-alpha-repository (most of them have PRs associated already). I'm
  hopeful for them be all upstreamed and available before the stable
  release of OCaml 4.10.


Data engineer positions at Elastic, US/Canada/Western Europe (proximate to NA timezones)
════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-data-engineer-positions-at-elastic-us-canada-western-europe-proximate-to-na-timezones/4991/1>


Hezekiah Carty announced
────────────────────────

  Our team here at [Elastic] has positions open for a few security data
  engineers (aka wranglers of data and all the systems involved).  We
  are a distributed company so you don't have to be close to an office
  to be considered.  Infosec industry experience is _not_ required,
  though of course welcome.  We're surrounded by experts in the field so
  you'll have lots of opportunities to learn as you go!

  The official postings are available here (both have the same text and
  only differ in title/seniority):
  • Security data engineer -
    <https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-data-engineer/2005140#/>
  • Senior security data engineer -
    <https://jobs.elastic.co/jobs/security-solutions/amer-distributed-/security-senior-data-engineer/2005152#/>

  Language-wise, OCaml/Reason makes up most of the code you’ll be
  working on. Python makes up most of the rest, in particular taking
  advantage of the machine learning and natural language processing
  goodies that ecosystem provides. Most of the tools and service we
  develop are internally focused, supporting security research and
  improvements to security protections for our users. For those
  so-inclined, there are lots of opportunities to present at and attend
  conferences, present work in blog posts, contribute to open source
  software projects and otherwise engage the community.

  The positions are very similar to our [last hiring announcement],
  though we had a different name at that point!

  Please reach out to me if you have any questions. I’m available on the
  OCaml or Reason Discord servers or by email at
  hezekiah.carty@elastic.co.


[Elastic] <https://www.elastic.co/>

[last hiring announcement]
<https://discuss.ocaml.org/t/filled-posting-is-no-longer-open-threat-research-engineer-job-endgame-us/1937>


Release of naboris 0.1.0 a simple http server
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/release-of-naboris-0-1-0-a-simple-http-server/4994/1>


Shawn McGinty announced
───────────────────────

  <https://github.com/shawn-mcginty/naboris>

  I could use input on the API and the documentation.  Working on trying
  to improve both at the moment.

  The goal was to create a very simple library for building RESTful type
  of web servers.  Make it _very_ easy to manage handle request/response
  lifecycle and sessions.

  In my opinion this type of web server is a great entry point for new
  developers looking to explore the OCaml/Reason world.

  Recently I have fallen in love with OCaml and Reason, and as a mostly
  web centered developer I've found this area quite lacking.  I'm still
  new to the language and eco system so any guidance would be highly
  appreciated!


Yawar Amin replied
──────────────────

  Wow! It seems we had much the same idea–OCaml/Reason more accessible
  to web developers new to the ecosystem :-D I've been working on
  something very similar: <https://github.com/yawaramin/re-web/>


Ulrik Strid said
────────────────

  There is also opium <https://github.com/rgrinberg/opium>

  And morph <https://github.com/reason-native-web/morph> that has
  similar goals.

  It would be nice if we could either create a shared core that all
  could build from or collaborate on one.


esy@0.6.0 release
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-esy-0-6-0-release/5010/1>


Andrey Popp announced
─────────────────────

  We've just released a new version of esy. You can install it with npm:
  ┌────
  │ $ npm install -g esy@0.6.0
  └────

  [esy] is a package.json driven workflow for native development with
  Reason/OCaml (and even C/C++). It provides per-project build
  environments which are isolated from each other but share underlying
  build caches so creating new environments is cheap.

  While 0.6.0 is mainly about "quality-of-life" improvements it also got
  few new features including a basic support for garbage collection of
  unused build artifacts.

  For more info see a [blog post] by @prometheansacrifice which
  highlights important updates in 0.6.0.


[esy] <https://esy.sh>

[blog post] <https://esy.sh/blog/2020/01/12/0.6.0.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]


[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: Type: text/html, Size: 53238 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-18  8:18 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-02-18  8:18 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

[-- Attachment #1: Type: text/plain, Size: 14952 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of February 11 to 18,
2020.

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

Logical 0.3.0
OCaml 4.10.0, first release candidate
New release of Menhir, including bug fixes
First release of data-encoding, JSON and binary serialisation
Opam package popularity?
What's the OCaml equivalent for HLint?
New release of naboris 0.1.1
Category theory for Programmers book - OCaml flavor
Call for Speakers: Build Meetup New York April 2020
Old CWN


Logical 0.3.0
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-logical-0-3-0/5150/1>


Tóth Róbert announced
─────────────────────

  I proud to announce that I published Logical 0.3.0 and it's available
  in opam. I'm also not to proud to announce that I did a bunch of
  breaking changes in this release. :D

  During development of this release, I realized that I made the biggest
  mistake I could do as a library maintainer, which is that I didn't use
  my own library, so I made a bunch of stupid design mistakes, which I
  hopefully fixed in this release.

  Changelog:
  • Added both_multi goal
  • Removed set from the type system
  • Moved type system to separate module
  • Re-factored state to be a map instead of an association list
  • Added bunch of examples to the bin folder

  One of my main goal with Logical was to solve the puzzles that I found
  in this entertaining article:
  <https://xmonader.github.io/prolog/2018/12/21/solving-murder-prolog.html>
  and it became a reality so hurray.  Another important thing to mention
  is that I can proudly say that Logical is capable of solving a mystery
  murder, so it's at least a mystery murder complete
  language/framework. :D

  Future plans(0.4.0 release):
  • I want to introduce conditions or validations (I need to find a good
    name for it) on the variables, which would basically be a function,
    which is run when the variable gets it's value, so it's possible to
    assess if the value is a good one or not. I think this feature is
    extremely general, flexible and powerful, so I have to be careful
    how I implement it(if I will). :D It also means that implementing
    negation in Logical will become a breeze, so that's it for being
    negation free.
  • I'm thinking of creating a Variable module, which will by more like
    a syntactic sugar for creating variables. I'm not sure about this,
    because this would make Goal.equal "obsolete".
  • I will hide Base's datatypes behind ours, so the user don't have to
    depend on base to use the library.

  Let me know if you have any suggestion or comment about Logical.

  Github: <https://github.com/StrykerKKD/Logical>
  Docs: <https://strykerkkd.github.io/Logical>


OCaml 4.10.0, first release candidate
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-10-0-first-release-candidate/5137/2>


octachron announced
───────────────────

  We have released a second release candidate to integrate a bug fix for
  32-bit users of the new best-fit allocator:

  <https://github.com/ocaml/ocaml/pull/9292>

  The fix should be transparent for other users, the release is mostly
  here to try to minimize the difference between the candidate and final
  binaries.


New release of Menhir, including bug fixes
══════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2020-02/msg00023.html>


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

  Dear users of OCaml & Menhir,

  It is my pleasure to announce a new release of Menhir.

  ┌────
  │ opam update
  │ opam upgrade menhir
  └────

  This release fixes two bugs in our implementation of Pager's
  algorithm.  Menhir relies on this algorithm to build an LR automaton
  and to decide which states can safely be merged, where "safely" means
  "without creating unexplainable conflicts". One bug (which had been
  known for a long time, but not fixed) would cause Menhir to sometimes
  make an unsafe merge decision, thereby creating an unexplainable
  conflict. The other bug (which had never been discovered until now)
  would cause Menhir to sometimes miss a safe merge decision, thereby
  creating an automaton with needlessly many states.

  In summary, after upgrading to this version, you may find (in some
  cases) that the parser produced by Menhir for your grammar has
  changed. It may have slightly more or slightly fewer states than the
  parser produced by previous versions of Menhir. Even in cases where
  the parser hasn't changed, the numbering of the states can be
  different.

  Feedback is welcome.

  Happy parsing,

  François Pottier
  francois.pottier@inria.fr
  <http://cambium.inria.fr/~fpottier/>


2020/02/11
╌╌╌╌╌╌╌╌╌╌

  • Re-implement Menhir's default algorithm for constructing LR(1)
    automata, namely Pager's algorithm. This closes issue #21 (reported
    by Andrej Bauer), a bug that would sometimes cause unexplainable
    conflicts to appear, because states were merged too
    aggressively. This also removes an unreported bug that would cause
    the automaton to have too many states, because states were *not*
    merged aggressively enough. In summary, the old and new construction
    algorithms differ: in many cases, the resulting automaton is
    unchanged, but in some cases, the automaton produced by the new
    algorithm may have slightly more or slightly fewer states.

  • Re-implement Menhir's algorithm for constructing automata in
    `--no-pager' mode. In this (undocumented) mode, Menhir does not
    merge any states, but allows itself to redirect a transition from a
    state `s' to a *larger* state `s''. This method yields an automaton
    whose states form a subset of the states of the canonical LR(1)
    automaton. It usually has significantly fewer states than the
    canonical automaton, and significantly more states than the
    automaton produced by Pager's algorithm. The new construction method
    removes an unreported bug that would cause the automaton to have too
    many states. The automaton produced by the new algorithm will
    usually have significantly fewer states than the automaton produced
    by the previous algorithm.

  • Re-implement Menhir's algorithms for constructing automata in
    `--lalr' and `--canonical' modes. The previous algorithms were
    correct, as far as we know, so the output of the new algorithms is
    the same, up to a possible renumbering of the states. The new
    algorithms are slightly faster.

  • Increase the maximum length of a production, which used to be 127,
    up to 1023. Display a polite error message if this length is
    exceeded. (Problem reported by Andreas Abel.)

  • The new switch `--timings-to <filename>' causes internal timing
    information to be written to the file `<filename>'.

  • A version of the library `fix' is now vendored (included) inside
    Menhir. This should have no impact for end users, but implies that
    `dune' 2.2.0 or later is required.


First release of data-encoding, JSON and binary serialisation
═════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-data-encoding-json-and-binary-serialisation/4444/8>


Raphaël Proust announced
────────────────────────

  The newly released version (0.2) addresses this. All the binary
  reading/writing primitives use `result' by default and have `_opt' and
  `_exn' variants.

  The JSON primitives are not yet changed because they rely on an
  external library that has more idiosyncratic error management. (This
  will eventually be fixed in a future version.)


Opam package popularity?
════════════════════════

  Archive: <https://discuss.ocaml.org/t/opam-package-popularity/5159/1>


Chet Murthy asked
─────────────────

  Is there someplace a database of opam packages and their popularity?
  Obviously it'd be inaccurate, but it'd still be interesting to see
  which packages are most-often downloaded via opam …..


Levi Roth replied
─────────────────

  The listing at <https://opam.ocaml.org/packages/index-popularity.html>
  has the download counts (I think for the latest month, not sure if
  that means past 30 days or since the start of the current calendar
  month) as title attributes on the table rows.


What's the OCaml equivalent for HLint?
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/whats-the-ocaml-equivalent-for-hlint/5167/1>


Fangyi Zhou asked
─────────────────

  I've been using OCaml for quite a while and one thing I've been
  looking for is a good linter, ideally something like the Haskell
  [HLint].

  I found [this] which seems quite old - latest release in 2012.

  Sorry if this has been raised previously.


[HLint] <https://github.com/ndmitchell/hlint>

[this] <http://mascot.x9c.fr/index.html>


"Aaron L. Zeng
──────────────

  Something similar, but not as featureful, is [ppx_js_style].  It's
  somewhat opinionated, but the checks aren't Jane Street-specific.


[ppx_js_style] <https://github.com/janestreet/ppx_js_style>


New release of naboris 0.1.1
════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/announce-new-release-of-naboris-0-1-1/5173/1>


Shawn McGinty announced
───────────────────────

  <https://github.com/shawn-mcginty/naboris>

  • *(much)* Better performance
  • API improvements


Category theory for Programmers book - OCaml flavor
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/category-theory-for-programmers-book-ocaml-flavor/3905/4>


Anton Kochkov announced
───────────────────────

  Thanks to @Arul the book was finished, and now is available for
  download here -
  <https://github.com/hmemcpy/milewski-ctfp-pdf/releases/tag/v1.4.0-rc1>

  Please, enjoy and report a feedback.


Call for Speakers: Build Meetup New York April 2020
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/call-for-speakers-build-meetup-new-york-april-2020/5174/1>


Jérémie Dimino announced
────────────────────────

  On April 7th and 8th, [Jane Street], [Bloomberg] and [Google] will be
  hosting a Build Meetup at the [Jane Street offices] in New York City.

  As we begin shaping our schedule, we are reaching out to a number of
  communities to find people who would like to participate in the
  event. Speaker sign-ups are now live [here].

  We are excited to announce that the keynote will be presented by the
  authors of the research paper “[From Laptop to Lambda: Outsourcing
  Everyday Jobs to Thousands of Transient Functional Containers]” which
  examines the exciting possibilities for build through the use of cloud
  functions.

  The entire event will be themed around all things build and test:
  Bazel, Buck, BuildStream, CMake, Dune, Goma, Pants, Recc and Remote
  Execution. In addition to this, we are interested in the growing
  surrounding ecosystems, such as editor integration and developer build
  experience as a whole.

  The meetup will run as follows: on day one, a series of talks will be
  presented along with breakfast, lunch and refreshments. This will be
  followed by an evening social at a nearby venue to continue the
  discussions from throughout the day.

  On the second day there will be an opportunity for broader community
  collaboration and discussion during our all day code sprint.

  We are looking for insightful and engaging talks and presentations on
  topics focused around build systems. Have you worked tirelessly for
  the past 6 months on a new feature for project foo you would like to
  showcase? Have you and your team spent the last year integrating the
  tool bar at your workplace? Do you have some comparisons to make
  between qux and quux that the community could benefit from?

  If so, we would love to [hear from you]!

  We welcome proposals for talks across the entire ecosystem. Each talk
  should ideally last 30 minutes, followed by time for questions.

  Keep your eyes out for meetup registration information, which will be
  sent separately over the next few weeks!


[Jane Street] <https://www.janestreet.com/>

[Bloomberg] <https://www.techatbloomberg.com/>

[Google] <http://www.google.com/>

[Jane Street offices] <https://www.janestreet.com/contact-us/nyc/>

[here]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>

[From Laptop to Lambda: Outsourcing Everyday Jobs to Thousands of
Transient Functional Containers]
<http://stanford.edu/~sadjad/gg-paper.pdf>

[hear from you]
<https://docs.google.com/forms/d/e/1FAIpQLSdtOR-oAcxmxxYpkSpTPSbsrR_eLwza6plhyAkBGA6UrLK5xw/viewform?usp=sf_link>


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: Type: text/html, Size: 28180 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-02-04  8:47 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-02-04  8:47 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

[-- Attachment #1: Type: text/plain, Size: 16468 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of January 28 to
February 04, 2020.

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

Multicore OCaml: January 2020 update
Use Case for Ephemerons?
`json-data-encoding' version 0.8 (was `ocplib-json-typed')
Developer position at Abacus Medicine, Copenhagen
Camlp5 version 7.11 release (4.10 compatibility)
Old CWN


Multicore OCaml: January 2020 update
════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/multicore-ocaml-january-2020-update/5090/1>


Anil Madhavapeddy announced
───────────────────────────

  Welcome to the January 2020 news update from the Multicore OCaml team!
  We're going to summarise our activites monthly to highlight what we're
  working on throughout this year. This update has kindly been assembled
  by @shakthimaan and @kayceesrk.

  The most common question we get is how to contribute to the overall
  multicore effort. As I [noted last year], we are now in the process of
  steadily upstreaming our efforts to mainline OCaml. Therefore, the
  best way by far to contribute is to test for regressions or
  opportunities for improvements in the patches that are outstanding in
  the main OCaml repository.

  A secondary benefit would be to review the PRs in the [multicore
  repository], but those tend to be more difficult to evaluate
  externally as they are being spotted as a result of stress testing at
  the moment. A negative contribution would be to raise discussion of
  orthogonal features or new project management mechanisms – this takes
  time and effort to reply to, and the team has a very full plate
  already now that the upstreaming has begun. We don't want to prevent
  those discussions from happening of course, but would appreciate if
  they were directed to the general OCaml bugtracker or another thread
  on this forum.

  We'll first go over the OCaml PRs and issues, then cover the multicore
  repository and our Sandmark benchmarking infrastructure. A new
  initiative to implement and test new parallel algorithms for Multicore
  OCaml is also underway.


[noted last year]
<https://discuss.ocaml.org/t/multicore-prerequisite-patches-appearing-in-released-ocaml-compilers-now/4408>

[multicore repository]
<https://github.com/ocaml-multicore/ocaml-multicore/pulls>

OCaml
╌╌╌╌╌

◊ Ongoing

  • [ocaml/ocaml#9082] Eventlog tracing system

    Eventlog is a proposal for a new tracing facility for OCaml runtime
    that provides metrics and counters, and uses the Binary Trace Format
    (CTF). The next step to get this merged is to incubate the tracing
    features in separate runtime variant, so it can be selected at
    application link time.

  • [ocaml/ocaml#8984] Towards a new closure representation

    A new layout for closures has been proposed for traversal by the
    garbage collector without the use of a page table. This is very much
    useful for Multicore OCaml and for performance improvements. The PR
    is awaiting review from other developers, and can then be rebased
    against trunk for testing and merge.

  • [ocaml-multicore/ocaml-multicore#187] Better Safe Points

    A patch to regularly poll for inter-domain interrupts to provide
    better safe points is actively being reviewed. This is to ensure
    that any pending interrupts are notified by the runtime system.

  • Work is underway on improving the marshaling (runtime/extern.c) in
    upstream OCaml to avoid using GC mark bits to represent visitedness,
    and to use a hash table (addrmap) implementation.


  [ocaml/ocaml#9082] <https://github.com/ocaml/ocaml/pull/9082>

  [ocaml/ocaml#8984] <https://github.com/ocaml/ocaml/pull/8984>

  [ocaml-multicore/ocaml-multicore#187]
  <https://github.com/ocaml-multicore/ocaml-multicore/issues/187>


◊ Completed

  The following PRs have been merged to upstream OCaml trunk:

  • [ocaml/ocaml#8713] Move C global variables to a dedicated structure

    This PR moves the C global variables to a "domain state"
    table. Every domain requires its own table of domain local
    variables, and hence this is required for Multicore runtime.

    This uncovered a number of [compatability issues] with the C header
    files, which were all included in the recent OCaml 4.10.0+beta2
    release via the next item.

  • [ocaml/ocaml#9253] Move back `caml_*' to thematic headers

    The `caml_*' definitions from runtime/caml/compatibility.h have been
    moved to provide a compatible API for OCaml versions 4.04 to
    4.10. This change is also useful for Multicore domains that have
    their own state.


  [ocaml/ocaml#8713] <https://github.com/ocaml/ocaml/pull/8713>

  [compatability issues] <https://github.com/ocaml/ocaml/issues/9205>

  [ocaml/ocaml#9253] <https://github.com/ocaml/ocaml/pull/9253>


Multicore OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The following PRs have been merged into the Multicore OCaml trees:

  • [ocaml-multicore/ocaml-multicore#275] Fix lazy behaviour for
    Multicore

    A `caml_obj_forward_lazy()' function is implemented to handle lazy
    values in Multicore Ocaml.

  • [ocaml-multicore/ocaml-multicore#269] Move from a global
    `pools_to_rescan' to a domain-local one

    During stress testing, a segmentation fault occurred when a pool was
    being rescanned while a domain was allocating in to it. The rescan
    has now been moved to the domain local, and hence this situation
    will not occur again.

  • [ocaml-multicore/ocaml-multicore#268] Fix for a few space leaks

    The space leaks that occurred during domain spawning and termination
    when performing the stress tests have been fixed in this PR.

  • [ocaml-multicore/ocaml-multicore#272] Fix for DWARF CFI for
    non-allocating external calls

    The entry to `caml_classify_float_unboxed' caused a corrupted
    backtrace, and a fix that clearly specifies the boundary between
    OCaml and C has been provided.

  • An effort to implement a synchronized minor garbage collector for
    Multicore OCaml is actively being researched and worked
    upon. Benchmarking for a work-sharing parallel stop-the-world branch
    against multicore trunk has been performed along with clearing
    technical debt, handling race conditions, and fixing segmentation
    faults. The C-API reversion changes have been tested and merged into
    the stop-the-world minor GC branch for Multicore OCaml.


[ocaml-multicore/ocaml-multicore#275]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/275>

[ocaml-multicore/ocaml-multicore#269]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/269>

[ocaml-multicore/ocaml-multicore#268]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/268>

[ocaml-multicore/ocaml-multicore#272]
<https://github.com/ocaml-multicore/ocaml-multicore/pull/272>


Benchmarking
╌╌╌╌╌╌╌╌╌╌╌╌

  • The [Sandmark] performance benchmarking infrastructure has been
    improved for backfilling data, tracking branches and naming
    benchmarks.

  • Numerical parallel benchmarks have been added to the Multicore
    compiler.

  • An [Irmin] macro benchmark has been included in Sandmark. A test for
    measuring Irmin's merge capabilities with Git as its filesystem is
    being tested with different read and write rates.

  • Work is also underway to implement parallel algorithms for N-body,
    reverse-complement, k-nucleotide, binary-trees, fasta,
    fannkuch-redux, regex-redux, Game of Life, RayTracing, Barnes Hut,
    Count Graphs, SSSP and from the MultiMLton benchmarks to test on
    Multicore OCaml.


[Sandmark] <http://bench2.ocamllabs.io/>

[Irmin] <https://irmin.org>


Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌

  • A chapter on Parallel Programming in Multicore OCaml is being
    written and an early draft will be made available to the community
    for their feedback. It is based on Domains, with examples to
    implement array sums, Pi approximation, and trapezoidal rules for
    definite integrals.


Acronyms
╌╌╌╌╌╌╌╌

  • API: Application Programming Interface
  • CTF: Common Trace Format
  • CFI: Call Frame Information
  • DWARF: Debugging With Attributed Record Formats
  • GC: Garbage Collector
  • PR: Pull Request
  • SSSP: Single Source Shortest Path


Nicolas Tollenaere asked
────────────────────────

  If I may ask a question, I am curious about the status of integration
  of effects into the type system. According to this page
  <https://ocamlverse.github.io/content/future_ocaml.html#typed-algebraic-effects>,
  original plan was to merge an untyped version of effect, before it was
  decided to integrate them into the system. I have seen this
  presentation of leo white on this matter
  <https://www.janestreet.com/tech-talks/effective-programming/> along
  with this one <https://www.youtube.com/watch?v=ibpUJmlEWi4> (from
  2016). My understanding was that, at the time of the last
  presentation, there was still some theoretical issues to be solved
  (although the speaker did not seem too worried about finding some way
  around eventually). I have no idea about the current status of the
  project. Reading your post it seems that you are now in an integration
  phase (PR reviews and all) that would imply that you're done with
  (most) theoretical questions. But that could either mean that you are
  integrating an untyped version of effects (and the type system is let
  for future development) or that you have indeed settled on a
  design. Which one is it ? Anyway, thanks for the post and the work in
  general, this project seems awesome (even if I did not dive into it
  too much until now)


Anil Madhavapeddy replied
─────────────────────────

  Good question; our current focus in getting the runtime components
  upstreamed (the "Domains" API) and some of the mechanisms that could
  be used by an effect system.  We haven't yet settled on a final design
  for an effect extension to OCaml, but the general preference is to
  skip integrating an untyped effect system if a typed version lands in
  the right timescales. This will happen after all the runtime pieces
  are upstreamed, which will allow everyone to use multicore parallelism
  via the lower-level Domains API.


Use Case for Ephemerons?
════════════════════════

  Archive: <https://discuss.ocaml.org/t/use-case-for-ephemerons/2838/3>


Continuing this old thread, Yawar Amin said
───────────────────────────────────────────

  [Here's another use] (disclaimer: this is my project).

  What's happening here is that I'm using an 'ephemeral cache' (i.e. a
  cache backed by an ephemeron hash table, [here]) to store subscribers
  to a 'topic', i.e. a pub-sub bus. You get a subscription token when
  you subscribe to a topic, and part of that token is the cache key. The
  cache is 'ephemeral' so as soon as the subscription token goes out of
  scope, it and its corresponding subscription (concretely, the stream
  and its push function) are automatically deleted from the cache.

  Hence, there's no 'unsubscribe' or 'close topic' functionality–it's
  assumed that you want to unsubscribe if you let the subscription token
  go out of scope.


[Here's another use]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Topic.ml>

[here]
<https://github.com/yawaramin/re-web/blob/766da0c0e06652824e34416bc518ee37197a90fb/ReWeb/Cache.ml#L41>


`json-data-encoding' version 0.8 (was `ocplib-json-typed')
══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-json-data-encoding-version-0-8-was-ocplib-json-typed/5095/1>


Raphaël Proust announced
────────────────────────

  I'm happy to announce that Nomadic Labs is now in charge of the
  development, maintenance and release of `json-data-encoding' – the
  library previously known as `ocplib-json-typed'. Even though we are
  changing to a more descriptive name, we are maintaining continuity of
  version numbers. As a result, this is an announce for the version
  `0.8'.

  The library `json-data-encoding' lets you define encodings for a given
  OCaml type, and use that encoding to encode values of that type into
  JSON or decode JSON into values of that type. The library supports
  multiple JSON backends: `Ezjsonm', `Yojson', native browser
  representation (for `js_of_ocaml', via the package
  `json-data-encoding-browser') and `BSON' (via the package
  `json-data-encoding-bson').

  It is available via `opam' (`opam install json-data-encoding') and
  hosted on <https://gitlab.com/nomadic-labs/json-data-encoding/>

  Changes from the version v0.7 include:
  • extensive tests using `Crowbar' (adapted from similar tests on
    `data-encoding' originally by @gasche)
  • minor documentation improvements
  • improved self documentation capabilities for unions' cases (work by
    @smondet)
  • improved schema equality (work by @rbardou)


Developer position at Abacus Medicine, Copenhagen
═════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/developer-position-at-abacus-medicine-copenhagen/5119/1>


mokn announced
──────────────

  Abacus Medicine has an open developer position. We do parallel
  distribution of medicine in EU and for that we have developed a system
  to handle the trading. A part of this system is developed in OCaml.

  Unfortunately the job description is only in danish, but we do accept
  applications in english: [Job description]


[Job description]
<https://www.jobindex.dk/jobannonce/351439/software-developer>


Camlp5 version 7.11 release (4.10 compatibility)
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-camlp5-version-7-11-release-4-10-compatibility/5121/1>


Chet Murthy announced
─────────────────────

  New release 7.11 of Camlp5. Compatible with all OCaml versions >=
  4.00.0, latest OCaml version 4.10+beta2 included.

  Main improvement: compatible with 4.10's blank module names and
  generative functors.

  Home page, including downloading and documentation at:
  <https://camlp5.github.io/>

  Enjoy!

  N.B. I'm new to helping out with camlp5, so might have made some
  mistakes; any users who find problems should contact me either
  directly, or (better) thru issues on
  <https://github.com/camlp5/camlp5/releases> and I'll be sure to get
  right on it.

  N.B.#2: There are still lots of gaps between current Ocaml, and
  Camlp5's support; I'm working on fixing that, and there'll soon be a
  release that brings camlp5 as up-to-date as possible with Ocaml.


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: Type: text/html, Size: 29138 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-28 10:53 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-01-28 10:53 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

[-- Attachment #1: Type: text/plain, Size: 8910 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of January 21 to 28,
2020.

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

New release of Menhir (20200123)
Ocaml cross compiler?
Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
Proper way to allocate an OCaml string from C code in OCaml 4.10?
OCaml 4.10.0, second beta
Old CWN


New release of Menhir (20200123)
════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2020-01/msg00040.html>


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

  It is my pleasure to announce a new release of Menhir, the LR(1)
  parser generator.

  ┌────
  │ opam update
  │ opam install menhir
  │ opam install coq-menhirlib # if you wish to use menhir --coq
  └────

  There are no new features, only a significant change in the manner in
  which Menhir is built:

  • Menhir is now built and installed by dune. This should make life
    easier for Menhir's developers: in particular, `make test' and `make
    speed' can be run straight away and do not requiring installing
    Menhir first. This should also make compilation much faster on
    multi-core machines. (Contributed by Nicolás Ojeda Bär, to whom many
    thanks are due.)

  • There used to be a distinction between two slightly different ways
    of installing Menhir, namely with and without `ocamlfind'. This
    distinction disappears. The command line switch
    `--suggest-ocamlfind' is deprecated and causes Menhir to print
    `false'.

  We hope that these changes do not break any of the code that relies on
  Menhir today. Please report any problems that you might
  encounter. Happy hacking!


Ocaml cross compiler?
═════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-cross-compiler/1494/7>


Deep in this thread, Dmitry Ponyatov asked
──────────────────────────────────────────

  What about embedded targets like Cortex-M (STM32F3/F4)?  How much
  memory should it have to have to run OCaml-compiled programs?


Ivan Gotovchits replied
───────────────────────

  You may find this [page] interesting. To summarize, with _a lot of
  work_ you can make a subset of OCaml programs runnable on a
  microcontroller. You will also need to rewrite OCaml's runtime and
  develop a new GC for it.

  In real life, no, you can't run OCaml on a microcontroller. You need
  at least a couple of megabytes of normal RAM with MMU.


[page] <http://www.algo-prog.info/ocapic/web/index.php?id=ocapic>


Ivan Gotovchits then added
──────────────────────────

  Hmm, found this [project], that is also quite relevant to you, it is
  quite alive, so maybe you have chances :)


[project] <https://github.com/stevenvar/OMicroB>


Two master internship proposals to explore social and technical aspects of the creation of the OCaml and Coq platforms
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/two-master-internship-proposals-to-explore-social-and-technical-aspects-of-the-creation-of-the-ocaml-and-coq-platforms/5073/1>


Théo Zimmermann announced
─────────────────────────

  We are looking for candidates for the following two internships
  intended to prefigure the creation of the OCaml and Coq platforms:
  • a first internship is focused on exploring technical aspects:
    <https://www.irif.fr/_media/users/theo/internship_proposal_platform_tech.pdf>
  • a second internship is focused on exploring social and policy
    aspects:
    <https://www.irif.fr/_media/users/theo/internship_proposal_platform_social.pdf>

  Please feel free to forward this announcement.  Interested students
  should send their resume and cover letter at
  [yrg@irif.fr](<mailto:yrg@irif.fr>) and
  [theo@irif.fr](<mailto:theo@irif.fr>).

  Yann Régis-Gianas (Inria, IRIF, OCaml Foundation) and Théo Zimmermann
  (Inria, IRIF, Coq development team)


Proper way to allocate an OCaml string from C code in OCaml 4.10?
═════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/proper-way-to-allocate-an-ocaml-string-from-c-code-in-ocaml-4-10/5075/1>


Rwmjones asked
──────────────

  Previously to allocate a string with explicit length (ie.  one which
  may contain \0 characters) in C code we have used:

  ┌────
  │ strv = caml_alloc_string (count);
  │ memcpy (String_val (strv), str, count);
  └────

  In OCaml 4.10 this doesn't compile because String_val returns a `const
  char *'.

  I could change String_val to Bytes_val, but that feels wrong.  The
  runtime seems to use `&Byte_u (strv, 0)'.

  It's a shame there's not a caml_copy_string_len function, but what is
  the proper way to do this for OCaml 4.10+, especially a way that won't
  break in future and will be compatible with multicore?


yallop suggested
────────────────

  You can use [`caml_alloc_initialized_string']:

  ┌────
  │ CAMLextern value caml_alloc_initialized_string (mlsize_t len, const char *);
  └────


[`caml_alloc_initialized_string']
<https://github.com/ocaml/ocaml/blob/d408e58ea15ec890a2c6d98441d261db51a6735d/runtime/caml/alloc.h#L38~>


OCaml 4.10.0, second beta
═════════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-4-10-0-second-beta/5083/1>


octachron announced
───────────────────

  The release of OCaml 4.10.0 is near. We have released a second beta
  version to help you adapt your softwares and libraries to the new
  features ahead of the release.

  This new beta contains an update to the internal runtime API that
  should make it easier to maintain compatibility across version for
  expert users; and a small fix for the analysis of recursive values.

  The source code is available at these addresses:

  <https://github.com/ocaml/ocaml/archive/4.10.0+beta2.tar.gz>
  <https://caml.inria.fr/pub/distrib/ocaml-4.10/ocaml-4.10.0+beta2.tar.gz>

  The compiler can also be installed as an OPAM switch with one of the
  following commands.
  ┌────
  │ opam switch create ocaml-variants.4.10.0+beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  or
  ┌────
  │ opam switch create ocaml-variants.4.10.0+beta1+<VARIANT> --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where you replace <VARIANT> with one of these:
  • afl
  • flambda
  • fp
  • fp+flambda

  For a better experience, you can use the opam alpha repository
  provided by:
  ┌────
  │ opam repository add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
  └────
  This repository contains a handful of temporary patched packages, that
  you can use while waiting for the packages to be properly patched.
  This repository should not be used in production and you probably want
  to install it only for the beta switch.

  We want to know about all bugs. Please report them here:

  <https://github.com/ocaml/ocaml/issues>


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: Type: text/html, Size: 21596 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-21 14:08 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-01-21 14:08 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of January 14 to 21,
2020.

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

How does the compiler check for exhaustive pattern matching?
resto 0.2 released
opam 2.0.6 release
soupault: a static website generator based on HTML rewriting
Spin: Project scaffolding tool and set of templates for Reason and OCaml
Old CWN


How does the compiler check for exhaustive pattern matching?
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/how-does-the-compiler-check-for-exhaustive-pattern-matching/5013/1>


Dylan Irlbeck asked
───────────────────

  Hi all. I'm relatively new to OCaml, and I was curious on how the
  compiler is able to give a warning when a case list is non-exhaustive
  - both from a high-level and, if possible, the implementation of this
  check. I have some ideas about how one could do this, but none of my
  ideas seem like they'd be nearly as efficient as the OCaml compiler
  is.


gasche replied
──────────────

  The canonical reference for exhaustivity-checking in OCaml is the
  scientific publication

        [Warnings for pattern matching] Luc Maranget 2007

  The general idea is to consider all the patterns of a given
  pattern-matching at once, generalize this structure to a "matrix" of
  patterns (matching on several values in parallel), and devise an
  algorithm to "explore" these pattern matrices in such a way that you
  eventually tell if a given pattern-matrix is exhaustive, or can
  propose a counter-example.

  (I guess we should write a high-level/accessible blog post about
  this.)


[Warnings for pattern matching]
<http://moscova.inria.fr/~maranget/papers/warn/index.html>


resto 0.2 released
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-resto-0-2-released/5028/1>


Raphaël Proust announced
────────────────────────

  On behalf on Nomadic Labs, I'm happy to announce the release of
  version 0.2 of `resto', a library to create type-safe HTTP/JSON
  services.

  The library is available through opam (`opam install resto'),
  distributed under LGPL, and hosted on
  <https://gitlab.com/nomadic-labs/resto>.

  `resto' was previously released as `ocplib-resto' maintained by
  OCamlPro. The project is now maintained by Nomadic Labs.

  Along with many bugfixes and a few added features, the main change of
  this release is that the library is split into multiple packages with
  fine-grained dependencies.


opam 2.0.6 release
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-0-6-release/5038/1>


R. Boujbel announced
────────────────────

  We are pleased to announce the minor release of [opam 2.0.6].

  This new version contains mainly build update & fixes. You can find
  more information in this [blog post].

  _opam is a source-based package manager for OCaml. It supports
  multiple simultaneous compiler installations, flexible package
  constraints, and a Git-friendly development workflow._


[opam 2.0.6] <https://github.com/ocaml/opam/releases/tag/2.0.6>

[blog post] <https://opam.ocaml.org/blog/opam-2-0-6>


soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/11>


Daniil Baturin announced
────────────────────────

  soupault 1.8.0 is [released] along with Lua-ML 0.9.1.

  Lua-ML now raises `Failure' when Lua code execution fails. There's
  much room for improvement in that area, for now I've just done
  something that is better than just displaying errors on stderr but
  otherwise allowing syntax and runtime errors pass silently.

  If you have any ideas how perfect interpreter error reporting _should_
  work, please share!

  As of improvements in soupault itself, there's now:
  • A way for plugins to specify their minimum supported soupault
    version like `Plugin.require_version("1.8.0")'
  • `TARGET_DIR' environment variable and `target_dir' Lua global that
    contains the directory where the rendered page will be written, to
    make it easier for plugins/scripts to place processed assets
    together with pages.
  • "Build profiles": if you add `profile = "production"' or similar to
    widget config, that widget will be ignored unless you run `soupault
    --profile production'.
  • A bunch of new utility functions for plugins.


[released] <https://soupault.neocities.org/blog/soupault-1.8.0-release/>


Spin: Project scaffolding tool and set of templates for Reason and OCaml
════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/spin-project-scaffolding-tool-and-set-of-templates-for-reason-and-ocaml/5047/1>


Mohamed Elsharnouby announced
─────────────────────────────

  <https://github.com/tmattio/spin>


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: Type: text/html, Size: 18137 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-01-07 13:43 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2020-01-07 13:43 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1: Type: text/plain, Size: 23631 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of December 31, 2019
to January 07, 2020.

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

ocaml-lsp preview
Mkocaml Release - Project generator
Garbage Collection, Side-effects and Purity
A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
Release of owl-symbolic 0.1.0
Static lifetime
Old CWN


ocaml-lsp preview
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/15>


Continuing this thread, Edwin Török said
────────────────────────────────────────

  Here is an example with ALE and Neovim (tested with v0.3.8):
  • Install the [Ale] plugin. If your Vim has support for packages (Vim
    8+ or Neovim) you can simply clone it in the correct subdir, no need
    for a plugin manager: `git clone https://github.com/w0rp/ale.git
    .vim/pack/my-plugins/start/ale'
  • Add this to your .vimrc:

  ┌────
  │ " only invoke merlin to check for errors when
  │ " exiting insert mode, not on each keystroke.
  │ let g:ale_lint_on_text_changed="never"
  │ let g:ale_lint_on_insert_leave=1
  │ 
  │ " enable ALE's internal completion if deoplete is not used
  │ let g:ale_completion_enabled=1
  │ 
  │ " only pop up completion when stopped typing for ~0.5s,
  │ " to avoid distracting when completion is not needed
  │ let g:ale_completion_delay=500
  │ 
  │ " see ale-completion-completeopt-bug
  │ set completeopt=menu,menuone,preview,noselect,noinsert
  │ 
  │ if has('packages')
  │     packloadall
  │ 
  │     " This should be part of ALE itself, like ols.vim
  │     call ale#linter#Define('ocaml',{
  │                 \ 'name':'ocaml-lsp',
  │                 \ 'lsp': 'stdio',
  │                 \ 'executable': 'ocamllsp',
  │                 \ 'command': '%e',
  │                 \ 'project_root': function('ale#handlers#ols#GetProjectRoot')
  │                 \})
  │ 
  │     " remap 'gd' like Merlin would
  │     nmap <silent><buffer> gd  <Plug>(ale_go_to_definition_in_split)<CR>
  │ 
  │     " go back
  │     nnoremap <silent> <LocalLeader>gb <C-O>
  │ 
  │     " show list of file:line:col of references for symbol under cursor
  │     nmap <silent><buffer> <LocalLeader>go :ALEFindReferences -relative<CR>
  │ 
  │     " Show documentation if available, and type
  │     nmap <silent><buffer> <LocalLeader>hh <Plug>(ale_hover)<CR>
  │ 
  │     " So I can type ,hh. More convenient than \hh.
  │     nmap , <LocalLeader>
  │     vmap , <LocalLeader>
  │ endif
  └────


[Ale] <https://github.com/dense-analysis/ale>


Mkocaml Release - Project generator
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/mkocaml-release-project-generator/4949/1>


Chris Nevers announced
──────────────────────

  I recently created a tool to generate OCaml projects. I constantly
  have difficulties with dune commands and setting up opam files,
  etc. Mkocaml generates a dune project with inline tests, opam file,
  git repository, git ignore, and a Makefile with easy commands. This
  tool can be of great help to newcomers, allowing them to get up and
  running faster!

  <https://github.com/chrisnevers/mkocaml>


Garbage Collection, Side-effects and Purity
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/garbage-collection-side-effects-and-purity/4737/1>


Gerard asked
────────────

  GC = Garbage Collection

  GC, in a pure program, is a point that's always confused me. I always
  understood that freeing memory from a program was impure and would
  create side-effects but it seems it doesn't matter if the program is
  remove from all consequences of those impure acts and side-effects.

  Basically, if any memory block has no remaining references in the
  program, then freeing that block will have no consequences on the
  running program so its allowed to happen behind the scenes..

  Is this correct reasoning?


Guillaume Munch-Maccagnoni replied
──────────────────────────────────

  To answer your question “does de-allocation creates a side-effect?”:

  To state the obvious: if you care about the memory consumption of your
  program, then you care about the side-effect of de-allocation, and
  this indeed voids purity.

  A language like OCaml lets you reason about de-allocation. Memory is
  collected when values are no longer reachable. Like in other
  languages, 1) a value that does not escape and goes out of scope will
  get collected, and 2) you can reason about when a value escapes and
  goes out of scope thanks to OCaml respecting the strict evaluation
  order of value types. OCaml (like other compiled languages) is in fact
  more precise: it ties the dynamic notion of reachability to the
  lexical notion of variable occurrence. For instance, in the following:

  ┌────
  │ let x = get_huge_data () in
  │ let z = long_running_function x in
  │ f z
  └────

  OCaml will be able to collect the value in `x' before `x' goes out of
  scope, and thus if possible before `long_running_function'
  returns. Indeed, OCaml performs liveness analysis during compilation,
  and records the information about variable occurrences in frame
  descriptors, for consumption by the GC when it scans for roots. In
  fact, you can rely on call-by-value operational semantics to (loosely)
  reason that a value no longer appears in a program, and therefore that
  the corresponding memory will be collected by the GC¹ ([Morrisett,
  Felleisen and Harper, "Abstract Models of Memory Management"]). Of
  course, using lazy or higher-order interfaces (when closures escape;
  with many idioms they do not) will make it harder to reason about the
  lifetime of values.

  (¹: For OCaml, this is a conjecture I make, for subsets which could be
  given such operational semantics, and only for native
  compilation. Morrisett, Felleisen and Harper's semantics obviously
  assumes that the results of liveness analysis are made available to
  the GC, but this is not written, nor is there any mention of the link
  between liveness analysis and accuracy of garbage collection in
  Appel's "Modern Compiler Implementation in C". I assume that it was
  part of folklore at the time, though recently I mentioned it to some
  functional PL researcher and they seemed surprised. I only found it
  explicitly mentioned in later papers from the OOP community. I checked
  that everything seems in place for OCaml to allow such reasoning, but
  only the authors of the original code, @xavierleroy and
  @damiendoligez, can tell us if this is intended to be part of the
  language semantics.)

  Furthermore, memory is not collected immediately when a value becomes
  unreachable. Instead:

  • Short-lived values are allocated contiguously and deallocated in a
    batch, so that allocating and deallocating short-lived values is
    very cheap, with additional benefits in terms of cache
    locality. This replaces stack allocation from languages with
    explicit memory management.

  • Longer-lived values are moved to a heap that is scanned
    incrementally, to ensure a bounded latency. In contrast, naive
    reference-counting and unique pointers from C++/Rust make you pay
    the cost of deallocation up-front.

  While this is essential for understanding the performance of OCaml
  programs, from the point of view of deallocation-as-an-effect, the
  delaying of the collection of unreachable memory can be seen as a
  runtime optimisation, that does not change the effectful status of
  deallocation (the memory still gets freed). [The intuition is that an
  effect can support some degree of reordering without requiring purity,
  as illustrated by strong monads which can be commutative without being
  idempotent, one possible definition of purity for semanticists.]

  But is de-allocation an effect _in practice_? Faced with the
  scepticism and misunderstandings from this thread, I emit two
  hypotheses:

  1) Memory consumption is not an issue in functional programming, for
     application areas that interest functional programmers.

  2) Memory management in OCaml is efficient in such a way that
     programmers do not need to think about it in their day-to-day
     programming activities in those terms.

  Hypothesis 2) could be explained for instance if OCaml programmers are
  already dealing with effects and thinking about the order in which
  their code executes (my experience), and are only used to deal with
  deallocation as an afterthought, e.g. when chasing leaks with a
  profiler.

  Let us turn towards two programming language experiments from the
  1990's that allow me to reject hypothesis 1). Both show what happens
  when one denies the status of deallocation as an effect controlled by
  the programmer.

  • Region-based memory management consisted in allocating in a stack of
    memory _regions_ deallocated at once, and determined by a
    whole-program static analysis. Now regarded as a failed idea but
    successful experiment (i.e. good science!), it taught us a lot about
    the structure of functional programs in relationship to memory
    management ([see this retrospective]). There were some good
    performance results, but also pathological cases _“where lifetimes
    were not nested or where higher-order functions were used
    extensively”_, sometimes requiring them to be altered to be _“region
    friendly”_, which was _“time-consuming”_ and required knowledge of
    the inference algorithm. In addition, the regions changed
    unpredictably when the programs evolved, and memory leaks appeared
    when the compiler inferred too wide regions.

  • Haskell was (at the time) an experiment with lazy functional
    programming. Pervasive laziness prevents reasoning about the
    lifetime of values, and purity is a central assumption used by the
    compiler for program transformations, which is antithetical with
    reasoning about deallocation as an effect. It is well-known that
    naive Haskell code has issues with memory leaks, and that realistic
    Haskell programs have to follow "best practices" to avoid leaks, by
    making extensive use of strictness annotations (e.g. bang
    patterns). Unfortunately, I found it hard to find reliable academic
    sources about lessons drawn from the experiment like the RBMM
    retrospective. The best I could find on the topic of memory leaks is
    the following blog post:
    <https://queue.acm.org/detail.cfm?id=2538488>, from a Haskell
    programmer who wrote in another post (linked from that one) _“My
    suspicion is that many (most?) large Haskell programs have space
    leaks, but they often go unnoticed”_. This is consistent with
    comments I received from people with Haskell experience (first-hand,
    one academic and one industrial) and about an industrial Haskell
    consultant (second-hand) who reportedly commented that their main
    job was to fix memory leaks (but maybe in jest). Of course, take
    this with a grain of salt. At least, I believe that the Haskell
    academic community has accumulated empirical evidence of the extent
    and manner in which deallocation voids purity assumptions. Having an
    authoritative source about it would be pretty important to me, given
    the initial promises of functional programs being more tractable
    mathematically specifically via “referential transparency” and
    independence of execution order, whose theoretical justification
    already looks shaky to me from a semantic point of view. Some parts
    of the literature continues to promise far-reaching consequences of
    equational reasoning, without clear statements of limitation of the
    application domain. I have the impression that the Haskell which is
    practiced in the real world is very different from what you can read
    in some academic papers.

  The hypothesis that deallocation matters as an effect, and that ML
  makes it easy to program and reason about effects, seems to me a
  strong argument explaining OCaml's predictable and competitive
  performance.

  So, thank you for your healthy scepticism.


[Morrisett, Felleisen and Harper, "Abstract Models of Memory
Management"] <https://dash.harvard.edu/handle/1/3293156>

[see this retrospective]
<https://link.springer.com/article/10.1023/B:LISP.0000029446.78563.a4>


Xavier Leroy replied
────────────────────

  Concerning the "don't scan local variables that are dead" trick:

  • Technically it is not "intended to be part of the language
    semantics" because the bytecode compiler (ocamlc) doesn't implement
    it, only the native-code compiler (ocamlopt).

  • As far as I remember, I reinvented this trick circa 1993, but it
    seems it was used earlier in the Lazy ML compiler by Augustsson and
    Johnsson. See Appel and Shao's paper "An Empirical and Analytic
    Study of Stack vs. Heap Cost for Languages with Closures", JFP,
    1996, end of section 5.


Guillaume Munch-Maccagnoni the asked
────────────────────────────────────

  TL;DR: the paper mentioned by @xavierleroy provides additional
  references regarding the importance of liveness analysis for GC,
  including a demonstration by Appel that this actually matters for
  space complexity (thanks!). I find that a link is still missing with
  an abstract semantics à la Morrisett, Felleisen & Harper. This seems
  important to me because more theoretical works about time & space
  complexity in the lambda-calculus seem to take for granted that
  garbage collection implements something like the latter (i.e., how
  does one specify and certify that a compiler is sound for space
  complexity?).


Xavier Leroy replied
────────────────────

  See for example [Closure Conversion is Safe for Space], by Zoe
  Paraskevopoulou and Andrew W. Appel, ICFP 2019.


[Closure Conversion is Safe for Space]
<https://www.cs.princeton.edu/~appel/papers/safe-closure.pdf>


A Lightweight OCaml Webapp Tutorial (Using Opium, Caqti, and Tyxml)
═══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/a-lightweight-ocaml-webapp-tutorial-using-opium-caqti-and-tyxml/4967/1>


Shon announced
──────────────

  The tutorial is [hosted on gitlab pages], out of [this repository].

  I put this together in response to some requests for introductory
  material on the topic (here and on [/r/ocaml]. I don't have much
  expertise to offer in this area, but I had hacked together some simple
  servers based on Opium in the past few months, so it seemed like I
  should be able to memorialize some of what I learned for the benefit
  of others. I received some critical guidance by the Opium maintainers,
  rgrinberg and anuragsoni, and from other resources online (mentioned
  at the end of the tutorial).

  Any feedback or improvements are welcome: this is my first time
  writing such lengthy instructional material, and I'm sure there's lots
  of room to make it better.


[hosted on gitlab pages] <https://shonfeder.gitlab.io/ocaml_webapp/>

[this repository] <https://gitlab.com/anuragsoni/ocaml_webapp>

[/r/ocaml] <https://www.reddit.com/r/ocaml/>


Release of owl-symbolic 0.1.0
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/2>


jrzhao42 announced
──────────────────

  The Owl tutorial book URL address is now changed to:
  <https://ocaml.xyz/book/symbolic.html>.


Static lifetime
═══════════════

  Archive: <https://discuss.ocaml.org/t/static-lifetime/4908/19>


André asked and Guillaume Munch-Maccagnoni replied
──────────────────────────────────────────────────

  > Is it possible to “statically” allocate a value? By this I mean mark
    a value such that it gets ignored by the GC and lives until the
    program exits?

  This is indeed the purpose of Ancient, which comes with limitations
  and does not allow you to reclaim the memory until you exit the
  program. (I am curious to know how well it works with recent OCaml
  versions.)

  > it would be really interesting to learn whether Ocaml forbids blocks
    outside the heap.

  The OCaml runtime has two modes (chosen at compilation) for dealing
  with so-called "out-of-heap" pointers. In the legacy one that Chet
  remembers, the GC uses a page table when scanning to be able to tell
  which pointers it possesses. In the "no-naked-pointers" mode devised
  more recently for efficiency reasons, the page table is replaced by
  looking at the colour in the header of the dereferenced
  value. Out-of-heap values must be preceded by a header with colour
  black. The no-naked-pointer mode is more restricted, because once a
  static value is referenced, it can no longer be deallocated, as you
  never know whether it is still reachable by the GC. This should be
  enough to support Ancient.

  > One should verify such intuitions experimentally, before trying to
    fix them, but I’m not familiar with what OCaml profilers can do…

  Excluding large long-lived data from the GC is an old idea. Among
  recent developments, Nguyen et al. [1] distinguish a "control path"
  (where the generational hypothesis is assumed to hold) from a "data
  path" (where values are assumed to follow an "epochal" behaviour
  (long-lived, similar lifetimes, benefit from locality), and are
  excluded from GC). They give as motivation so-called "big data" and as
  figures of pathological GC usage up to 50% of total runtime. I
  remember reading similar figures from blog posts about large data sets
  in OCaml. In reality this indeed depends on knobs you can turn on your
  GC that can result in increased peak memory usage among
  others. (Assuming infinite available memory, it is even possible to
  let the GC share drop to 0%.)

  @ppedrot reported to me that in a recent experiment with Coq, using an
  Ancient-like trick to exclude some large, long-lived and
  rarely-accessed values from being scanned (namely serialising them
  into bigarrays), they saw an 8% performance improvement across the
  board in benchmarks.

  Multicore, if I understood correctly, aims to support only the
  no-naked-pointer mode, and I am not sure what the page table will
  become. Coq currently does some out-of-heap allocation in the VM, and
  has been adapted to be compatible with the no-naked-pointer mode by
  wrapping out-of-heap pointers into custom blocks. For scanning its
  custom stack (which mixes in-heap and out-of-heap values), Coq sets up
  a custom root-scanning function (`caml_scan_roots_hook`), which still
  relies on the page table.

  Note that having to wrap out-of-heap pointers in custom blocks is
  (much!) less expressive: for instance with Ancient you can call
  `List.filter` on a statically-allocated list (and correctly get a
  GC-allocated list of statically-allocated values). With custom blocks
  you cannot mix in-heap and out-of-heap values in this way.

  For a type system to deal with "statically" allocated values, have a
  look at Rust, which: 1) prevents cycles of reference-counting schemes
  thanks to uniqueness, 2) can treat GC roots as resources to deal with
  backpointers at the leaves of the value (cf. the interoperability with
  SpiderMonkey's GC in Servo). A point of view that I like is that
  tracing GCs and static allocation differ fundamentally by how they
  traverse values for collection: traversing live values for the first
  one, and traversing values at the moment of their death for the
  other. This gives them distinct advantages and drawbacks so one can
  see them as complementary. (See notably [2,3].) Static allocation is
  interesting for performance in some aspects (no tracing, no read-write
  barrier, reusability of memory cells, avoids calling the GC at
  inappropriate times), but I find it even more interesting for
  interoperability (e.g. exchanging values freely with C or Rust, or
  [applications from that other thread]). It is natural to want to mix
  them in a language.

  As far as I understand, developing the runtime capabilities for OCaml
  to deal with out-of-heap pointers without resorting to an expensive
  page table is an engineering problem, not a fundamental one. If anyone
  is interested in this, please contact me.

  [1] Nguyen et al., [Yak : A High-Performance Big-Data-Friendly Garbage
  Collector], 2016

  [2] Bacon, Cheng and Rajan, [A Unified Theory of Garbage Collection],
  2004

  [3] Shahriyar, Blackburn and Frampton, [Down for the Count? Getting
  Reference Counting Back in the Ring], 2012


[applications from that other thread]
<https://discuss.ocaml.org/t/using-a-bigarray-as-a-shared-memory-for-parallel-programming/4841/19>

[Yak : A High-Performance Big-Data-Friendly Garbage Collector]
<https://www.usenix.org/system/files/conference/osdi16/osdi16-nguyen.pdf>

[A Unified Theory of Garbage Collection]
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.439.1202&rep=rep1&type=pdf>

[Down for the Count? Getting Reference Counting Back in the Ring]
<https://dl.acm.org/citation.cfm?doid=2258996.2259008>


UnixJunkie also replied
───────────────────────

  If you can store your long-leaved data into a bigarray, I think you
  would reach the effect that you were looking for (no more GC scanning
  of this data).

  This was once advised to me by Oleg, for some performance-critical
  section of some code.


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: Type: text/html, Size: 35507 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-31  9:18 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-12-31  9:18 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1: Type: text/plain, Size: 14554 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of December 17 to 31,
2019.

Sorry for the hiatus last week, I was away with no internet
access. Happy new year!

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

Internships at Be Sport (OCaml, Ocsigen)
ocaml-lsp preview
Reproducible builds with OCaml / opam and MirageOS
the OCaml Software Foundation
soupault: a static website generator based on HTML rewriting
Release of owl-symbolic 0.1.0
Old CWN


Internships at Be Sport (OCaml, Ocsigen)
════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00023.html>


Be Sport announced
──────────────────

  Be Sport currently has several open internship positions for OCaml
  developers.

  Keywords: OCaml, Ocsigen, Mobile app development, Web, Database,
  Sport, Social networks

  Be Sport develops the first global platform dedicated to sport, in
  collaboration with prominent actors of sport in France and in the
  world.  All our development is done in OCaml. Our Web and mobile apps
  (iOS, Android) are developed as a multi-tier app using the Ocsigen
  framework.  Our premises are located in the center of Paris.

  Please contact me for more information.


ocaml-lsp preview
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocaml-lsp-preview/4876/1>


Rudi Grinberg announced
───────────────────────

  I'm excited to announce [ocaml-lsp]. This project contains an
  implementation of an LSP server for the OCaml language. The current
  implementation piggy backs on the widely successful [merlin] tool to
  provide completion & type inference. In the future, we'd like to use
  all other essential tools such as ocamlformat, odoc, dune to provide
  more functionality in your editors.

  For now, the project isn't yet available on opam as we're still
  polishing some rough edges in the release process. Nevertheless, I
  invite all brave souls who are ready to experiment to give this lsp
  server a try. Your feedback & contributions are most welcome
  :slight_smile:


[ocaml-lsp] <https://github.com/ocaml/ocaml-lsp>

[merlin] <https://github.com/ocaml/merlin>


UnixJunkie asked and Anton Kochkov replied
──────────────────────────────────────────

        This project looks nice.

        If I am an Emacs or Vi user, can I take advantage of an
        LSP server?

        Or, is this only for some new editors like Atom or VScode?

  @UnixJunkie of course! That's the whole point of this tooling.

  For Vim you can choose between:
  • [Coc.nvim] - most powerful of all, but written in TypeScript and
    heaviest of all
  • [Ale] - pure VimL
  • [vim-lsp] - pure VimL
  • [LanguageClient-neovim] - written in Rust
  • Some other implementations

  I am not an Emacs expert, but there is amazing LSP integration too:
  • [lsp-mode]

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/b/b8acd745527e801fef1eb3d4e8722d49c5c2ed1a.png>


[Coc.nvim] <https://github.com/neoclide/coc.nvim>

[Ale] <https://github.com/dense-analysis/ale>

[vim-lsp] <https://github.com/prabirshrestha/vim-lsp>

[LanguageClient-neovim]
<https://github.com/autozimu/LanguageClient-neovim>

[lsp-mode] <https://github.com/emacs-lsp/lsp-mode>


Pau Ruiz Safont said
────────────────────

  Neovim 0.5.0 (now pre-released) has native LSP support as well:
  <https://github.com/neovim/neovim/pull/11336>

  Not sure how well integrated is it going to be with various plugins
  ([example])


[example] <https://github.com/Shougo/deoplete-lsp>


Anton Kochkov added
───────────────────

  NeoVim 0.5.0 will also include the [tree-sitter] parser for syntax
  highlighting, which will allow way better coloring. And tree-sitter
  already has [OCaml grammar], so implementing semantics-aware syntax
  highlighter will be easier. But I expect the support more or less
  ready for external contributions only in 0.6.0, sadly. Integrating the
  tool with something like [GitHub Semantic] (*Haskell alert*) will
  greatly improve OCaml experience on GitHub too, see the [corresponding
  issue].


[tree-sitter] <https://tree-sitter.github.io/tree-sitter/>

[OCaml grammar] <https://github.com/tree-sitter/tree-sitter-ocaml>

[GitHub Semantic] <https://github.com/github/semantic>

[corresponding issue] <https://github.com/github/semantic/issues/138>


Pieter Goetschalckx said
────────────────────────

  The next step for Semantic support is documented [here], but I'm
  working on some [improvements] of the tree-sitter parser first.


[here]
<https://github.com/tree-sitter/haskell-tree-sitter/blob/master/docs/codegen.md>

[improvements]
<https://github.com/tree-sitter/tree-sitter-ocaml/pull/36>


Carlos D'Agostino said
──────────────────────

  For Emacs there is also `eglot': <https://github.com/joaotavora/eglot>
  – As the README says, it's quite minimalist compared to `lsp-mode'.


Reproducible builds with OCaml / opam and MirageOS
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/reproducible-builds-with-ocaml-opam-and-mirageos/4877/1>


Hannes Mehnert announced
────────────────────────

  I wrote up recent developments about reproducible builds with opam –
  including some tooling <https://hannes.nqsb.io/Posts/ReproducibleOPAM>

  Thanks to everyone involved in the effort to get OCaml and opam
  deterministic
  • Nov 2015 [I collected downstream patches and asked kindly to get
    them upstream] (temporary flle names in binaries, timestamps)
  • Dec 2017 [BUILD_PATH_PREFIX_MAP support] (and further patches for
    that)
  • Dec 2018 Paris summit [opam reproducibility] [MirageOS]
  • [`orb'] tool for reproducibility testing (so much better than the
    shell scripts I used in the meantime)
  • Dec 2019 [Marrakesh summit]

  The journey is not yet finished, we're in a pretty good shape, but
  further testing and tooling is needed to expose the information "is my
  library reproducible?" to OCaml developers.

  I'm interested in feedback, please let us discuss this further here in
  case you're interested. :D


[I collected downstream patches and asked kindly to get them upstream]
<https://github.com/ocaml/ocaml/issues/7037>

[BUILD_PATH_PREFIX_MAP support]
<https://github.com/ocaml/ocaml/pull/1515>

[opam reproducibility]
<https://reproducible-builds.org/events/paris2018/report/#Toc11410_331763073>

[MirageOS]
<https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>

[`orb'] <https://github.com/rjbou/orb>

[Marrakesh summit]
<https://reproducible-builds.org/events/Marrakesh2019/>


Anil Madhavapeddy added
───────────────────────

  An absolutely amazing cross-layer effort; well done on pushing all
  this through @hannes!  I really enjoyed reading the minutes of the
  Paris summit last year:
  <https://reproducible-builds.org/events/paris2018/report/#Toc11681_331763073>


the OCaml Software Foundation
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/13>


Continuing this thread, gasche announced
────────────────────────────────────────

  A small report on the actions that we launched since my initial
  posting.

  (There was also some progress on the "enabling individual donations"
  front, maybe something will be possible in the next few months. Don't
  start holding your breath yet.)

  • We are funding the "Leafs" research project in Lisbon to develop
    teaching material for theoretical-computer-science courses (automata
    and stuff) in OCaml, with interactive visualization components, some
    of which will hopefully be integrated in the [Learn-OCaml] platform
    over the course of 2020/2021.
  • We provide funding for the [Gallium/Cambium] research team at INRIA
    Paris (France), an active place for OCaml-related fundamental
    research (some of the team members are also very active on the
    implementation front, for example Xavier Leroy, Damien Doligez,
    Florian @octachron Angeletti, and Sébastien Hinderer).
  • We sponsor the [SWERC] programming contest for 2019-2020, and in
    return the contest added OCaml to the list of available
    languages. Most participants to these competitive-programming events
    use C++, but we talked to past and active participants who said they
    would be interested in using OCaml on some problems with more
    symbolic computation.
  • Over the course of the 4.10 release process, we are funding work by
    @kit-ty-kate to have a wide look at the ecosystem and improve
    compatibility with the upcoming release. (I believe that the
    upstream PR [#9176] is a first result of this effort.)
  • In reaction to the Discourse thread [Suggestions for OCaml
    documentation], we are planning to fund further work by @sanette to
    experiment with the HTML rendering of the OCaml manual, in
    coordination with @octachron to try to upstream improvements when
    reasonably possible.
  • We got in touch with the [Owl] project to sponsor a development
    sprint in 2020.


[Learn-OCaml] <http://ocaml-sf.org/learn-ocaml.html>

[Gallium/Cambium] <http://cambium.inria.fr/>

[SWERC] <https://swerc.eu/2019/about/>

[#9176] <https://github.com/ocaml/ocaml/pull/9176>

[Suggestions for OCaml documentation]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>

[Owl]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>


soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/10>


Daniil Baturin announced
────────────────────────

  Made a [1.7.0 release].

  First improvement is that you now can pipe the content of any element
  through any external program with `preprocess_element' widget (PR by
  Martin Karlsson).  For example, insert inline SVG versions of all
  graphviz graphs from `<pre class="language-graphviz">' and also
  highlight the Dot source itself with [highlight] (or any other tool of
  your choice):

  ┌────
  │ [widgets.graphviz-svg]
  │   widget = 'preprocess_element'
  │   selector = 'pre.language-graphviz'
  │   command = 'dot -Tsvg'
  │   action = 'insert_after'
  │ 
  │ [widgets.highlight]
  │   after = "graphviz-svg"
  │   widget = "preprocess_element"
  │   selector = '*[class^="language-"]'
  │   command = 'highlight -O html -f --syntax=$(echo $ATTR_CLASS | sed -e "s/language-//")'
  │   action = "replace_content" # default
  └────

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a4d8cc05d65634de0faf3c05b16e0de8d27a78a3.png>

  Two other improvements are multiple index "views" and default value
  option for custom index fields, like
  ┌────
  │ [index.custom_fields]
  │   category = { selector = "span#category", default = "Misc" }
  └────


[1.7.0 release]
<https://soupault.neocities.org/blog/soupault-1.7.0-release>

[highlight] <http://andre-simon.de>


Release of owl-symbolic 0.1.0
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/announce-release-of-owl-symbolic-0-1-0/4930/1>


jrzhao42 announced
──────────────────

  We are please to release [owl-symbolic 0.1.0]. It fully supports
  defining a computation graph and running on accelerators (TPU/GPU) via
  [ONNX] specification. It also aims to support converting an Owl
  computation graph into symbolic representation and then to ONNX
  model. The module also has some cool features like converting a
  computation graph into LaTeX string, and then showing the result in a
  web UI, etc.

  We implements a full neural network module atop of it (the interface
  of which is basically identical to that in Owl's core). It turns out
  that the design of `owl-symbolic' is so nice that the DNN module only
  has 179 LOC! You can easily define popular DNN architectures such as
  Inception, ResNet, VGG, etc. just like in Owl.

  This is still an on-going project and a lot remains to be
  done. Despite its name, `owl-symbolic' does not do any useful computer
  algebra (CAS) stuff at the moment, but CAS is indeed on our TODO.

  For more information, please check out the related section in [Owl
  tutorial book].


[owl-symbolic 0.1.0] <https://opam.ocaml.org/packages/owl-symbolic/>

[ONNX] <https://onnx.ai/>

[Owl tutorial book] <https://ocaml.xyz/owl_tutorials/symbolic.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]


[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: Type: text/html, Size: 26832 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-17  8:52 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-12-17  8:52 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 6972 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of December 10 to 17,
2019.

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

Is there a good way to encode linear types in OCaml?
Arch Linux installer written in OCaml
batteries batteries.2.11.0
Old CWN


Is there a good way to encode linear types in OCaml?
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/is-there-a-good-way-to-encode-linear-types-in-ocaml/1292/7>


Continuing this old thread, Konstantin Olkhovskiy said
──────────────────────────────────────────────────────

  I've stumbled upon a library that implements linear types for OCaml,
  using monads, lens and some ppx to make it more lightweight. Might be
  of interest: <https://github.com/keigoi/linocaml>


Anton Kochkov added
───────────────────

  It is the part of even more interesting system - [OCaml MPST]
  (Multiparty Session Types) See the [slides].


[OCaml MPST] <https://github.com/keigoi/ocaml-mpst>

[slides]
<https://www.slideshare.net/keigoi/ocamlmpst-global-protocol-combinators-175519214>


Guillaume Munch-Maccagnoni then said
────────────────────────────────────

  (The paper linked on that page is dated 2011/2014. In case anyone
  wonders whether the authors have found a time machine in a barn to be
  able to cite papers from 2018, there just seems to be an error in the
  preparation. It is freshly published, and a PDF with correct dates is
  available [here].)


[here]
<https://www.jstage.jst.go.jp/article/ipsjjip/27/0/27_431/_article>


Arch Linux installer written in OCaml
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/arch-linux-installer-written-in-ocaml/4388/12>


Darren announced
────────────────

  I'm doing a short update here as Oali has seen some significant
  changes. This update is also the last one here to avoid being too
  annoying, and also since I won't be add too much new stuff to Oali in
  foreseeable future.

  Major changes since last time
  • SaltStack files and script files (or profiles) now live in a
    separate [repo]
    • Oali accepts custom profile repo URL to facilitate using your own
      SaltStack files without forking Oali itself
  • Semi self-documentation
    • Added mechanism to facilitate inline documentation inside
      `oali.ml' itself
    • The generated markdown doc is stored as [OALI_DOC] in repo, it
      lists all the steps (or tasks) Oali does, along with descriptions
  • Added LVM support
    • Works with all 3 disk layouts, and encryption
    • See [here] for details on added logical volumes
  • Answer remembering of dialogues when appropriate
    • Relatively static answers (e.g. hostname, whether to use
      encryption, LVM) are stored in `oali_answers' directory, with a
      JSON file for each task
    • The "answer store" can be used in new session of Oali. The old
      answer store is wiped accordingly if user changes their answer.
  • Added SSH server setup and public key transfer code (ported from old
    server bash script)
    • See [here] for details
    • Mainly useful for when you have (virtual) console access to live
      CD/Oali install screen, and want to add needed public key to the
      user's `.ssh/authorized_keys' via network instead of loading from
      physical medium

  I've used Oali to install in various configurations in past couple of
  days, and have yet to notice major defects. That being said, exercise
  caution as you would for installing an OS.


[repo] <https://github.com/darrenldl/oali-profiles>

[OALI_DOC] <https://github.com/darrenldl/oali/blob/master/OALI_DOC.md>

[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#20-set-up-disk>

[here]
<https://github.com/darrenldl/oali/blob/master/OALI_DOC.md#54-transfer-ssh-public-keys>


batteries batteries.2.11.0
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-batteries-batteries-2-11-0/4871/1>


UnixJunkie announced
────────────────────

  The latest 2.x release of batteries is available in opam.  OCaml
  batteries included is a community maintained extended standard
  library.

  <https://github.com/ocaml-batteries-team/batteries-included>

  The API documentation is hosted here:
  <https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>

  Here is the changelog:
  ┌────
  │ v2.11.0 (minor release)
  │ 
  │ This minor release fixes a few bugs or interface mismatch with OCaml stdlib,
  │ and is compatible with BER MetaOCaml.
  │ 
  │ This is the last planned release of the v2 series.
  │ Next planned release (v3.0.0) will introduce some API changes.
  │ 
  │ Notable changes:
  │ 
  │     Add Unix.with_locked_file
  │     #904
  │     (Simon Cruanes, Cedric Cellier, review by Francois Berenger)
  │ 
  │     Build with -strict-sequence
  │     #927
  │     (Armaël Guéneau, review by Francois Berenger)
  │ 
  │     Add Legacy.Result for OCaml >= 4.8.0
  │     #913
  │     (Cedric Cellier, review by Francois Berenger)
  │ 
  │     Remove BatOo
  │     #915
  │     (Cedric Cellier, review by Francois Berenger)
  │ 
  │     Add BatFilename
  │     #910
  │     (Cedric Cellier, review by Francois Berenger)
  │ 
  │     Make batteries usable with BER MetaOCaml
  │     #909
  │     (Cedric Cellier, review by Francois Berenger and Gabriel Scherer)
  │ 
  │     Unix.sleepf is provided across all OCaml versions;
  │     previously it was only for OCaml >= 4.03.0
  │     #930
  │     (Francois Berenger, review by Cedric Cellier)
  └────


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 #1.1.2: Type: text/html, Size: 18093 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-10  8:21 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-12-10  8:21 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 4145 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of December 03 
to 10,
2019.

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

Internships at Nomadic-labs
Interesting OCaml Articles
Next OUPS meetup December 18th 2019
Old CWN


Internships at Nomadic-labs
═══════════════════════════

  Archive: 
  <https://discuss.ocaml.org/t/internship-at-nomadic-labs/4819>


Julien Tesson announced
───────────────────────

  Nomadic Labs is currently looking for students with an interest 
  in
  functional programming for internships that would take place in 
  our
  offices in Paris or Grenoble.

  We have a catalog of internships topics available at [1] The
  internships topics are mainly addressed to master student but 
  other
  well motivated application will be considered.

  A first selection phase on received résumé will occur on 
  december
  15th.  Please contact us at contact@nomadic-labs.com by 
  specifying
  which topics in the catalog you're interested in.

  [1]: <https://nomadic-labs.com/download/internship_catalog.pdf>

  Please, feel free to redistribute widely.


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/57>


james woodyatt announced
────────────────────────

  Found on *Lobste.rs*: Mark Karpov writes yet another [Haskell
  vs. OCaml] for old time's sake. I found it worth a read and a 
  mention
  here.

  p.s. He spends a bit of time in the intro lamenting the lack of 
  a
  conventional Unicode string library for OCaml, and I feel that 
  pain
  acutely, especially since I'm the author of an *unconventional* 
  one,
  i.e. the [Ucs_text] module in my [Orsetto] project.


[Haskell vs. OCaml] 
<https://markkarpov.com/post/haskell-vs-ocaml.html>

[Ucs_text]
<https://bitbucket.org/jhw/orsetto/src/default/src/ucs/ucs_text.mli>

[Orsetto] <https://bitbucket.org/jhw/orsetto>


Next OUPS meetup December 18th 2019
═══════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2019-12/msg00009.html>


Bruno Bernardo announced
────────────────────────

  The OUPS meetup is back. The next one will take place on 
  Wednesday,
  December 18, 7pm at IRILL on the Jussieu campus. As usual, we 
  will
  have a few talks, followed by pizzas and drinks.

  The talks will be the following:

  • Nathan Rebours, The future of OCaml-PPX

  • Guillaume Claret, coq-of-ocaml
    (<https://clarus.github.io/coq-of-ocaml/>)

  And possibly a third talk. Contact us if you want to present
  something, especially if you have a small project you want to 
  show in
  10-15min.

  To register, or for more information, go here:
  <https://www.meetup.com/ocaml-paris/events/267019458>

  *Registration is required! Access is not guaranteed after 7pm if
  you're not registered.* (It also helps us to order the right 
  amount of
  food.)

  Access map:
  IRILL - Université Pierre et Marie Curie (Paris VI)
  Barre 15-16 1er étage
  4 Place Jussieu
  75005 Paris
  <https://www.irill.org/pages/access.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]


[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 #1.1.2: Type: text/html, Size: 15372 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-12-03 15:42 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-12-03 15:42 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 22620 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of November 26 
to
December 03, 2019.

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

Irmin 2.0.0 release
How viable is delivering binaries linked to Cygwin to Windows 
customers?
Dune 2.0.0
Advanced C binding using ocaml-ctypes and dune
Upcoming breaking change in Base/Core v0.14
CI/CD Pipelines: Monad, Arrow or Dart?
Use of functors to approximate F# statically resolved type 
parameters
Old CWN


Irmin 2.0.0 release
═══════════════════

  Archive: 
  <https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/5>


Continuing this thread, samoht announced
────────────────────────────────────────

  And there is now a follow-up blog post, explaining how to use 
  the new
  GraphQL API available in Irmin2:
  <https://tarides.com/blog/2019-11-27-introducing-irmin-graphql>.


How viable is delivering binaries linked to Cygwin to Windows 
customers?
════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/how-viable-is-delivering-binaries-linked-to-cygwin-to-windows-customers/4775>


mbacarella asked
────────────────

  I’m in the early stages of planning a deliverable binary product 
  that
  will run on Linux, Mac and Windows.

  My brief sniff of the air around the OCaml ecosystem says I 
  should
  expect to target Cygwin to get Windows going (although there’s
  impressive work to get native Windows stuff done that can become 
  the
  preferred approach in a few years).

  My experience using Cygwin as an operating environment is that 
  it’s
  pretty darn sluggish compared to Linux on the same computer.

  Why is this? There’s an anecdote that says Cygwin can only fork 
  at
  about 30-50x a second on Windows, due to how it has to adapt it 
  to
  work within Windows’ task spawning model. (For contrast, Linux 
  can
  achieve thousands of forks per second if you play around with 
  it).

  I understand from another product developer that when they build
  binaries to deliver to Windows/Cygwin, they actually 
  cross-compile on
  Linux because of how slowly the toolchain runs on Cygwin.

  That sounds like bad news if you want to do UNIXy things, but 
  for a
  single standalone application this might not be so bad? I assume 
  if I
  ship a deliverable to Windows/Cygwin, the end user may enjoy 
  good
  performance, so long as I’m not spawning tons of processes or 
  relying
  on fork for multi-programming. Is this a safe assumptions?

  Any other gotchas when it comes to OCaml on Cygwin w.r.t. 
  performance?

  The app pretty much has real-time gaming requirements (though 
  it’s not
  a game so can side-step worrying about access to GPUs and
  what-not). Stated another way, although my application will 
  depend on
  the POSIX layer offered by Cygwin, I expect it not to crunch 
  POSIX
  related stuff in the main loop.

  How has your experience gone?


John Whitington replied
───────────────────────

  I have been shipping commercial binaries for Linux (32 and 64 
  bit),
  Windows (32 and 64bit) and OS X for years. For example:
  <https://github.com/coherentgraphics/cpdf-binaries>

  And even static or shared libraries in binary form:
  <https://github.com/coherentgraphics/cpdflib-binary>

  On OS X, you need to use MACOSX_DEPLOYMENT_TARGET or similar to 
  make
  sure your builds will run on older systems. And, in fact, you 
  need to
  use MACOSX_DEPLOYMENT_TARGET when asking OPAM to compile the 
  OCaml
  compiler itself. And, you will need to deal with codesigning and
  notarization. But it’s all doable.

  For linux, you may need to build under older linux versions, to 
  make
  sure that the glibc in use is old enough. This is not an
  ocaml-specific problem. I have a 64 bit and 32 bit VM with 
  old-ish
  glibc versions for this purpose.

  Under Windows, there are no such backward-compatibility 
  problems. I
  use the new OCaml for windows system, which comes with OPAM, and 
  is
  mingw-based. No cygwin remains in the final binary.

  For more obscure systems (AIX, HPUX, Sparc etc) customers 
  compile from
  source (with help from me). Not once in more than ten years has 
  anyone
  cared that it was written in OCaml.


dbuenzli also replied
─────────────────────

  remember that on the Windows native port, the Unix module 
  distributed
  with OCaml is your POSIX compatibility layer. There are a few 
  entry
  points to avoid though, the list is at the bottom of [this 
  page].


[this page] 
<https://caml.inria.fr/pub/docs/manual-ocaml/libunix.html>


nojb also replied
─────────────────

  At LexiFi our main application is developed and shipped on 
  Windows. We
  use the msvc port of OCaml. This means that you need Cygwin to
  develop, but the resulting application is fully native and does 
  not
  depend on the Cygwin DLL. As @dbuenzli mentioned, the Unix 
  module *is*
  the POSIX compatibility layer.

  Compilation speed is slower on Windows because process creation 
  is
  slower on Windows as a general rule, but it is manageable (our
  application has around 2000 modules + Js_of_ocaml + C bindings + 
  C#
  component).

  We don’t have any issues with runtime performance. The `Unix' 
  library
  mentioned above implements Windows support directly without 
  going
  through any compatibility layer and is quite efficient.


BikalGurung also replied
────────────────────────

  There is an editor being built in ocaml/reasonml which currently
  targets windows, linux and macos -
  <https://github.com/onivim/oni2>. However, the binary is native
  windows rather than cygwin derivative. So if you don’t have to 
  use
  cygwin dependencies then native windows binary could be the way 
  to go.

  Also esy - <https://github.com/esy/esy> makes developing
  ocaml/reasonml on windows viable.


keleshev also replied
─────────────────────

  *TLDR*: Install the [Mingw port of OCaml 4], freely use most 
  opam
   libraries, and compile to native Windows binaries, without 
   licensing
   issues.

  I recommend you read the “Release notes for Windows”:
  <https://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc>

  To summarise, there are three Windows ports:

  • Native Microsoft port,
  • Native Mingw port,
  • Cygwin port.

  All three require Cygwin for development purposes. I recommend 
  using
  the Native Mingw, as:

  • it *doesn’t* require Visual Studio (it uses a mingw fork of 
  GCC that
    “cross-compiles” native Windows executables),
  • it *doesn’t* rely on the dreaded cygwin.dll
  • it has good opam support with opam-repository-mingw:
    <https://github.com/fdopen/opam-repository-mingw>
  • it has a convenient installer:
    <https://fdopen.github.io/opam-repository-mingw/> 5.

  To contrast, Native Microsoft requires Visual Studio, and 
  doesn’t have
  opam. You can still vendor pure OCaml packages, but as soon as 
  you
  want to use some C bindings you’re in trouble, because of the 
  “minor”
  differences between Visual C and GCC. And everything assumes GCC
  nowadays.

  Cygwin port is the one I don’t have experience with, but 
  re-reading
  the “Release notes for Windows” above it strikes me that it 
  mentions
  that Cygwin was re-licensed from GPL to LGPL with static linking
  exception. So it looks like the Cygwin port could be viable for
  commercial use, but I never tried to statically linked 
  `cygwin.dll',
  and I’m not sure what are the benefits of Cygwin port over the 
  Mingw
  port.


[Mingw port of OCaml 4]
<https://fdopen.github.io/opam-repository-mingw/>


dmbaturin also replied
──────────────────────

  With [soupault 4], I decided to ship prebuilt binaries for all
  platforms including Windows. Mostly to see if I can, all its 
  users I
  know of are on UNIX-like systems and know how to build from 
  source,
  but that’s beside the point. :wink:

  I can confirm everything @keleshev says: fdopen’s package just 
  works,
  opam works exactly like it does on UNIX, pure OCaml libraries 
  are
  trivial to install, and the binaries don’t depend on cygwin. 
  Note
  that “opam switch create” also just works, you can install 
  either
  MinGW or MSVC compiler versions as opam switches.  I only ever 
  start
  the Windows VM to make release builds, and the workflow is 
  exactly the
  same as on Linux where I’m actually writing code.

  My only obstacle on that path was that FileUtils lost its 
  Windows
  compatibility, but I wanted to use it, so I worked with 
  @gildor478 to
  make it cross-platform again. Uncovered a bug in the 
  implementation of
  Unix.utimes in the process, but it’s hardly a commonly used 
  function.

  You can also setup AppVeyor builds. It’s not as simple as I wish 
  it
  would be, but there are projects doing it that you can steal the 
  setup
  from.

  There’s also opam-cross-windows, but it’s very incomplete and 
  needs
  work to be practical. There are no big obstacles, it just needs
  work. While files in opam-repository-mingw are normally 
  identical to
  the default opam repository, the cross one needs small 
  adjustments in
  every package to specify the toolchain to use, so the required 
  work is
  mostly a lot of trivial but manual actions. I hope eventually it
  reaches parity with fdopen’s one and we’ll be able to easily 
  build for
  Windows without ever touching Windows.

  As of static Linux builds, @JohnWhitington’s approach can work, 
  but
  there’s a better option if you don’t need anything from glibc
  specifically and don’t link against any C libs: build statically 
  with
  musl. There’s a `+musl+static+flambda' compiler flavour. You 
  need musl
  and gcc-musl to install it, but after that, just build with 
  `-ccopt
  -static' flag and you get a binary that doesn’t depend on 
  anything.


[soupault 4] <https://soupault.neocities.org/>


Dune 2.0.0
══════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>


rgrinberg announced
───────────────────

  On behalf of the dune team, I’m delighted to announce the 
  release of
  dune 2.0. This release is the culmination of 4 months of hard 
  work by
  the dune team and contains new features, bug fixes, and 
  performance
  improvements . Here’s a selection of new features that I 
  personally
  find interesting:

  • New boostrap procedure that works in low memory environments
  • (`deprecated_library_name' ..) stanza to properly deprecate 
  old
    library names
  • (`foreign_library' ..) stanza to define C/C++ libraries.
  • C stubs directly in OCaml executables

  Refer to the change log for an exhaustive list.

  We strive for a good out of the box experience that requires no
  configuration, so we’ve also tweaked a few defaults. In 
  particular, `$
  dune build' will now build `@all' instead of `@install', and
  ocamlformat rules are setup by default.

  Lastly, dune 2.0 sheds all the legacy related to jbuilder and 
  will no
  longer build jbuilder projects. This change is necessary to ease
  maintenance and make it easier to add new features down the
  line. There are a few other minor breaking changes. Refer to the
  change log for the full list. We apologize in advance for any
  convenience this might cause.

  [Changelog]


[Changelog] <https://discuss.ocaml.org/t/ann-dune-2-0-0/4758>


Advanced C binding using ocaml-ctypes and dune
══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/advanced-c-binding-using-ocaml-ctypes-and-dune/4805>


toots announced
───────────────

  I worked on a socket.h binding last summer and had a great 
  experience
  integrating ocaml-ctypes with dune, I thought that might be of
  interest to other developers so I wrote about it:
  <https://medium.com/@romain.beauxis/advanced-c-binding-using-ocaml-ctypes-and-dune-cc3f4cbab302>


rgrinberg replied
─────────────────

  This is a good article. I encourage anyone who writes C bindings 
  with
  ctypes to study it carefully.

  A little bit of advice to shorten your dune files:

  ┌────
  │ (deps    (:gen ./gen_constants_c.exe))
  └────

  This line isn’t necessary. Dune is smart enough to know that 
  running a
  binary in a rule incurs a dependency on it.

        dune has a truly amazing [support for cross-compiling],
        which we do not cover here, but, unfortunately, its
        primitives for building and executing binaries do not yet
        cover this use case.

  Indeed, we don’t have any primitives for running binaries on the
  target platform. Perhaps we should add some. However, we do in 
  fact
  have some features in dune to solve this concrete cross 
  compilation
  problem. As far as I understand, the goal is to obtain some 
  compile
  time values such as #define constants and field offsets for the 
  target
  platform. This does not in fact require to run anything on the 
  cross
  compilation target. In configurator, we have a primitive
  `C_define.import' to extract this information. The end result is 
  that
  these configurator scripts are completely compatible with cross
  compilation.

  Perhaps this could be generalized to work with ctypes generators 
  as
  well?

  Funny bit of trivia: The hack in configurator required to do 
  this is
  in fact something I extracted from ctypes itself. The original 
  author
  is [whitequark], who in turn wrote it to make ctypes itself 
  amendable
  to cross compilation.


[support for cross-compiling]
<https://dune.readthedocs.io/en/latest/cross-compilation.html>

[whitequark] <https://github.com/whitequark>


emillon then added
──────────────────

        This does not in fact require to run anything on the cross
        compilation target. In configurator, we have a primitive
        `C_define.import' to extract this information. The end
        result is that these configurator scripts are completely
        compatible with cross compilation.

  If anybody wants to know more about this bit, I wrote an article 
  about
  this last year: 
  <https://dune.build/blog/configurator-constants/>


Upcoming breaking change in Base/Core v0.14
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/upcoming-breaking-change-in-base-core-v0-14/4806>


bcc32 announced
───────────────

  We’re changing functions in Base that used to use the 
  polymorphic
  variant type `[ `Fst of 'a | `Snd of 'b ]' to use `('a, 'b) 
  Either.t'
  instead. As well as enabling the use of all of the functions in 
  the
  Either module, this makes the functions consistent with other
  functions that already use `Either.t', (currently just
  `Set.symmetric_diff')

  The following functions’ types will change:
  • `Result.ok_fst'
  • `List.partition_map'
  • `Map.partition_map', `Map.partition_mapi'
  • `Hashtbl.partition_map', `Hashtbl.partition_mapi'

  The type of List.partition3_map will not change:

  ┌────
  │ val partition3_map
  │   :  'a t
  │   -> f:('a -> [ `Fst of 'b | `Snd of 'c | `Trd of 'd ])
  │   -> 'b t * 'c t * 'd t
  └────

  We don’t have a generic ternary variant, and it doesn’t seem 
  worth it
  to mint one just for this purpose.

  Since this change is pretty straightforward, we expect that a 
  simple
  find/replace will be sufficient to update any affected call 
  sites.


CI/CD Pipelines: Monad, Arrow or Dart?
══════════════════════════════════════

  Archive: 
  <https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>


Thomas Leonard announced
────────────────────────

  In this post I describe three approaches to building a language 
  for
  writing CI/CD pipelines. My first attempt used a monad, but this
  prevented static analysis of the pipelines. I then tried using 
  an
  arrow, but found the syntax very difficult to use. Finally, I 
  ended up
  using a light-weight alternative to arrows that I will refer to 
  here
  as a dart (I don’t know if this has a name already). This allows 
  for
  static analysis like an arrow, but has a syntax even simpler 
  than a
  monad.

  <https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>


Use of functors to approximate F# statically resolved type 
parameters
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/use-of-functors-to-approximate-f-statically-resolved-type-parameters/4782>


cmxa asked
──────────

  I am learning OCaml coming from F#. In F#, to calculate the 
  average of
  an array whose element type supports addition and division, one 
  can
  write

  ┌────
  │ let inline average (arr: 'a[]) : 'a
  │     when ^a : (static member DivideByInt : ^a * int -> ^a)
  │     and  ^a : (static member (+) : ^a * ^a -> ^a)
  │     and  ^a : (static member Zero : ^a)
  │     =
  │     if Array.length arr = 0 then 
  (LanguagePrimitives.GenericZero) else
  │     LanguagePrimitives.DivideByInt (Array.fold (+) 
  (LanguagePrimitives.GenericZero) arr) (Array.length arr)
  └────

  My understanding is that in OCaml, one would have a module type 
  like
  so:

  ┌────
  │ module type Averagable = sig
  │   type 'a t
  │
  │   val divide_by_int : 'a -> int -> 'a
  │   val plus : 'a -> 'a -> 'a
  │   val zero : 'a
  │ end
  └────

  My question is how the corresponding function would be written:

  ┌────
  │ let average arr =
  │   ???
  └────


smolkaj replied
───────────────

  First, `Averagable' should look like this:

  ┌────
  │ module type Averagable = sig
  │   type t
  │   val divide_by_int : t -> int -> t
  │   val plus : t -> t -> t
  │   val zero : t
  │ end
  └────

  Then average will look something like this:

  ┌────
  │ let average (type t) (module A : Averagable with type t = t) 
  (arr : t array) : t =
  │   Array.fold ~init:A.zero ~f:A.plus arr
  └────

  (The code above uses Jane Street’s Base/Core library.)


ivg then added
──────────────

  While @smolkaj’s answer is a correct and direct implementation 
  of your
  F# code, it might be nicer if your code can interplay with 
  existing
  abstractions in the OCaml infrastructure. For example,

  ┌────
  │ open Base
  │
  │ let average (type a) (module T : Floatable.S with type t = a) 
  xs =
  │   Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
  │   Float.of_int (Array.length xs)
  └────

  and now it could be used with any existing numeric data in 
  Base/Core

  ┌────
  │ average (module Int) [|1;2;3;4|];;
  │ - : Base.Float.t = 2.5
  └────

  and even adapted to non-numbers,

  ┌────
  │ let average_length = average (module struct
  │     include String
  │     let to_float x = Float.of_int (String.length x)
  │     let of_float _ = assert false
  │   end)
  └────

  The latter example shows that we requested more interface than 
  need, a
  cost that we have to pay for using an existing definition. In 
  cases
  when it matters, you can specify the specific interface, e.g.,

  ┌────
  │ module type Floatable = sig
  │   type t
  │   val to_float : t -> float
  │ end
  │
  │ let average (type a) (module T : Floatable with type t = a) xs 
  =
  │   Array.fold ~init:0. ~f:(fun s x -> s +. T.to_float x) xs /.
  │   Float.of_int (Array.length xs)
  └────

  But we reached the point where using first class modules is 
  totally
  unnecessary. Our interface has only one function, so the 
  following
  definition of average, is much more natural

  ┌────
  │ let average xs ~f =
  │   Array.fold ~init:0. ~f:(fun s x -> s +. f x) xs /.
  │   Float.of_int (Array.length xs)
  └────

  it has type `'a array -> f:('a -> float) -> float' and computes 
  an
  average of `f x_i' for all elements in the array.


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 #1.1.2: Type: text/html, Size: 41191 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-26  8:33 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-11-26  8:33 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 28861 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of November 19 
to 26,
2019.

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

tiny_httpd 0.1
printbox.0.3
v0.13 release of Jane Street packages
opam2nix (v1)
GitHub Actions for OCaml / opam now available
OCurrent 0.1 (CI/CD pipeline eDSL)
New pages for OCaml API
Irmin 2.0.0 release
Tail cascade: a new indentation style for some OCaml constructs
Old CWN


tiny_httpd 0.1
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-tiny-httpd-0-1/4727/1>


Simon Cruanes announced
───────────────────────

  Hello and good morning, I'm pleased to announce that 
  [tiny_httpd] 0.1
  has been released and is on opam.

  The goal is to emulate python's standard `http.server' by 
  providing a
  0-dependencies, minimalist, simple HTTP server for embedding in
  applications that are not primarily a website, with very basic 
  routing
  (thanks to `Scanf'). A binary `http_of_dir' is also distributed 
  and
  can be used to serve a directory, with optional upload of files.


[tiny_httpd] <https://github.com/c-cube/tiny_httpd>


printbox.0.3
════════════

  Archive: <https://discuss.ocaml.org/t/ann-printbox-0-3/4731/1>


Simon Cruanes announced
───────────────────────

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/8/8e7c55c5ab69c12f53a7862d2f84dd6e0cfc0dc0.png>

  ┌────
  │ let b =
  │   let open PrintBox in
  │   PrintBox_unicode.setup();
  │   frame @@ grid_l [
  │     [text "subject"; text_with_style Style.bold "announce: 
  printbox 0.3"];
  │     [text "explanation";
  │     frame @@ text {|PrintBox is a library for rendering nested 
  tables,
  │     trees, and similar structures in monospace text or 
  HTML.|}];
  │     [text "github";
  │     text_with_style Style.(bg_color Blue) 
  "https://github.com/c-cube/printbox/releases/tag/0.3"];
  │     [text "contributors";
  │      vlist_map (text_with_style Style.(fg_color Green)) 
  ["Simon"; "Guillaume"; "Matt"]];
  │     [text "dependencies";
  │     tree empty
  │       [tree (text "mandatory")
  │ 	 [text "dune"; text "bytes"];
  │        tree (text "optional")
  │ 	 [text "uutf"; text "uucp"; text "tyxml"]]];
  │     [text "expected reaction"; text "🎉"];
  │   ]
  │
  │ let () = print_endline @@ PrintBox_text.to_string b
  └────

  ([actual link to the release])


[actual link to the release]
<https://github.com/c-cube/printbox/releases/tag/0.3>


v0.13 release of Jane Street packages
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735/1>


Xavier Clerc announced
──────────────────────

  We are pleased to announce the v0.13 release of Jane Street 
  packages!

  This release comes with 14 new packages, and a number of fixes 
  and
  enhancements. The documentation for this release is available on 
  our
  website:

  <https://ocaml.janestreet.com/ocaml-core/v0.13/doc/>

  The remainder of this mail highlights the main changes since the 
  v0.12
  release; we hope it will be useful to developers in the process 
  of
  migrating to the new version. A comprehensive changelog is 
  available
  at the end.


Notable changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Changed `Base', `Core_kernel', and `Core' functions to raise
    `Not_found_s' instead of `Not_found'.  `Hashtbl.find_exn' and
    `Map.find_exn' now include the key in their error message.

  • Changed `Core' and `Core_kernel' to export `int' comparison 
  rather
    than polymorphic comparison.

  • Removed the "robust" float comparison operators (`>.', `=.', 
  …)
    from the default namespace.

  • Replaced `sexp_*' types (`sexp_list', `sexp_option', 
  `sexp_opaque',
    …) with preprocessor attributes (`[@sexp.list]', 
    `[@sexp.option]',
    `[@sexp.opaque]', …).

  • Changed `let%map' syntax from `let%map.Foo.Let_syntax' to
    `let%map.Foo'.

  • Added to `match%optional' support for specifying a path, so 
  you can
    write `match%optional.Foo foo_option' rather than `let open
    Foo.Optional_syntax in match%optional foo_option'.

  • Improved `Base.Backtrace' so that it enables recording of 
  backtraces
    in more situations, specifically when `OCAMLRUNPARAM' is 
    defined but
    doesn't mention the backtrace flag, `b'.

  • Added javascript support for `Zarith', `Bigint', `Bignum', and
    `Bigdecimal'.

  • Changed `Hashtbl.create''s default `size' from 128 to 0.

  • Changed `Core_kernel.Command' so that all commands accept 
  double
    dash flags: `--help', `--version', and `--build-info'.


New packages
╌╌╌╌╌╌╌╌╌╌╌╌

  • async_udp (<https://github.com/janestreet/async_udp>): UDP 
  support
    for Async.

  • async_websocket 
  (<https://github.com/janestreet/async_websocket>): A
    library that implements the websocket protocol on top of 
    Async.

  • bonsai (<https://github.com/janestreet/bonsai>): A library for
    building dynamic webapps, using Js_of_ocaml.

  • postgres_async 
  (<https://github.com/janestreet/postgres_async>):
    OCaml/async implementation of the postgres protocol (i.e., 
    does not
    use C-bindings to libpq).

  • ppx_cold (<https://github.com/janestreet/ppx_cold>): Expands
    `[@cold]' into `[@inline never][@specialise never][@local 
    never]'.

  • ppx_pattern_bind 
  (<https://github.com/janestreet/ppx_pattern_bind>):
    A ppx for writing fast incremental bind nodes in a pattern 
    match.

  • ppx_python (<https://github.com/janestreet/ppx_python>):
    `[@@deriving]' plugin to generate Python conversion functions.

  • ppx_yojson_conv 
  (<https://github.com/janestreet/ppx_yojson_conv>):
    `[@@deriving]' plugin to generate Yojson conversion functions.

  • ppx_yojson_conv_lib
    (<https://github.com/janestreet/ppx_yojson_conv_lib>): Runtime 
    lib
    for `ppx_yojson_conv'.

  • pythonlib (<https://github.com/janestreet/pythonlib>): A 
  library to
    help writing wrappers around OCaml code for python.

  • sexp_select (<https://github.com/janestreet/sexp_select>): A 
  library
    to use CSS-style selectors to traverse sexp trees.

  • timezone (<https://github.com/janestreet/timezone>): Time-zone
    handling.

  • toplevel_backend 
  (<https://github.com/janestreet/toplevel_backend>):
    Shared backend for setting up toplevels.

  • zarith_stubs_js 
  (<https://github.com/janestreet/zarith_stubs_js>):
    Javascript stubs for the Zarith library.


Deprecations / Removals
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  `Async_kernel':

  • Deprecated monadic `ignore' functions in favor of `ignore_m'.

  `Base':

  • Deleted `Array.replace' and `replace_all' functions, which 
  have been
    deprecated since before the last public release.

  • Deprecated `Result.ok_unit'; use `Ok ()'.

  • Removed the `Monad' and `Applicative' interfaces' `all_ignore'
    function; it was previously deprecated and replaced by 
    `all_unit'.

  • Removed `List.dedup', which has been deprecated since 2017-04.

  • Removed `String' mutation functions, which have been 
  deprecated in
    favor of `Bytes' since 2017-10.

  • Deprecated `Array.truncate', `Obj_array.unsafe_truncate', and
    `Uniform_array.unsafe_truncate'.

  • Deprecated `Sys.argv', which has been superseded by 
  `get_argv',
    which is a function, reflecting the fact that `argv' can 
    change (as
    of OCaml 4.09).

  `Core_kernel':

  • Removed `Core_kernel.Std', which had been deprecated for a 
  year.

  • Deprecated type `Command.Spec.param' in favor of 
  `Command.Param.t'.

  • Removed `Hashtbl' functions that had been deprecated for 
  years.

  • Removed `Float.to_string_round_trippable', which has been 
  deprecated
    in favor of `to_string' since 2017-04.

  • Deprecated `Fqueue' functions where one should use `Fdeque' 
  instead:
    `bot', `bot_exn', and `enqueue_top'.

  • Deleted `Bus.unsubscribes', which will be obviated by a 
  performance
    improvement to `Bus.unsubscribe'.

  `Timing_wheel':

  • Removed the `alarm_upper_bound' function, which has been 
  deprecated
    for 6 months, and superseded by `max_allowed_alarm_time'.


Moves
╌╌╌╌╌

  `Core_kernel':

  • Moved `Bounded_int_table' to a standalone library.

  • Moved the `Pool' and `Tuple_type' modules to a standalone 
  library,
    `Tuple_pool'.

  `Async_unix':

  • Moved `Unix.Fd.replace' into a `Private' submodule.


Changelog
╌╌╌╌╌╌╌╌╌

  Please visit
  <https://discuss.ocaml.org/t/ann-v0-13-release-of-jane-street-packages/4735>


opam2nix (v1)
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam2nix-v1/4741/1>


Tim Cuthbertson announced
─────────────────────────

  Anouncing opam2nix (v1)

  [opam2nix] generates [nix] expressions from the [opam] OCaml 
  package
  repository. It works similarly to [bundix], [node2nix], etc:

  You run an (impure) command to resolve all transitive dependency
  versions using the current opam repository, generating a .nix 
  file
  that locks down the exact package sources and versions. Then 
  this file
  can be imported to provide `buildInputs' for building your ocaml
  project in nix.

  *What is nix and why would I care?* Well, that's a long story 
  but the
   headline benefits of nix are:

  • reproducible builds (if it builds for me, it builds for you)
  • stateless (you don't set up switches and then install 
  packages, each
    expression specifies everything it needs, and anything you 
    don't
    have is fetched/built on demand)
  • language agnostic (takes care of non-ocaml dependencies)

  It's sadly not a shallow learning curve, but those benefits are 
  hard
  to find elsewhere, so I obviously think it's worthwhile. So if 
  you use
  nix (or would like to), please give it a try and provide
  feedback. I'll (slowly) start working on upstreaming it into 
  nixpkgs.


[opam2nix] <https://github.com/timbertson/opam2nix>

[nix] <https://nixos.org/>

[opam] <https://opam.ocaml.org/>

[bundix] <https://github.com/nix-community/bundix>

[node2nix] <https://github.com/svanderburg/node2nix>


GitHub Actions for OCaml / opam now available
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745/1>


Anil Madhavapeddy announced
───────────────────────────

  I was in the [GitHub Actions] beta program and forward ported my 
  code
  to the latest version that just went public.  It's a pretty 
  simple way
  to get your OCaml code tested on Linux, macOS and Windows, 
  without
  requiring an external CI service.  The action attempts to 
  provide a
  homogenous interface across all three operating systems, so 
  invoking
  'opam' from subsequent actions should "just work".

  You can find it here:
  • In the GitHub Marketplace at
    <https://github.com/marketplace/actions/setup-ocaml>
  • Source code on <https://github.com/avsm/setup-ocaml/>
  • Hello World usage on
    <https://github.com/avsm/hello-world-action-ocaml>
  • Usage in ocaml-yaml:
    • 
    <https://github.com/avsm/ocaml-yaml/blob/master/.github/workflows/test.yml>
    • An [example ocaml-yaml run]

  This should be considered fairly experimental as GH Actions is 
  so new.
  If you do use it, then consider [updating this issue with your 
  usage].
  It does not current supporting caching yet, but is pretty fast 
  to
  bootstrap (~4minutes).

  It also doesn't have any higher level purpose other than to set 
  up an
  opam environment, since most of the additional functionality 
  such as
  revdeps testing is planned for addition to the [ocurrent DSL].
  Nevertheless, this GH feature will hopefully be useful for 
  smaller
  projects without a lot of computational requirements.  Let me 
  know how
  it goes!

  Windows is currently supported through @fdopen's excellent fork 
  that
  uses Cygwin.  As Windows support is being mainlined into opam 
  itself
  at the moment, I'm hoping that we will gradually move over to 
  that.
  That should eventually remove the need for two separate
  opam-repositories, so I won't be adding any features that are 
  Linux or
  macOS-specific and do not work on the Cygwin version.


[GitHub Actions] <https://github.com/actions>

[example ocaml-yaml run]
<https://github.com/avsm/ocaml-yaml/runs/314055554>

[updating this issue with your usage]
<https://github.com/avsm/setup-ocaml/issues/4>

[ocurrent DSL]
<https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/2>


OCurrent 0.1 (CI/CD pipeline eDSL)
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocurrent-0-1-ci-cd-pipeline-edsl/4742/1>


Thomas Leonard announced
────────────────────────

  [OCurrent] 0.1 has just been released to opam-repository.

  OCurrent is an OCaml eDSL intended for writing build/test/deploy
  pipelines. It is being used as the engine for [ocaml-ci] and the
  [docker-base-images] builder (used to build the OCaml Docker 
  images,
  such as `ocurrent/opam:alpine-3.10-ocaml-4.08'). Other good uses 
  might
  be building and redeploying a Docker service or a unikernel 
  whenever
  its source repository changes. It can be run locally as a single 
  Unix
  process.

  An OCurrent pipeline is written as an OCaml program, but the 
  OCurrent
  engine ensures that it is kept up-to-date by re-running stages 
  when
  their inputs change. A web UI is available so you can view your
  pipeline and see its current state.

  OCurrent can statically analyse the pipelines before they have 
  run,
  allowing it to run steps in parallel automatically and to 
  display the
  whole pipeline. It does this using a light-weight alternative to
  arrows, which doesn't require programming in an awkward 
  point-free
  style. See [CI/CD Pipelines: Monad, Arrow or Dart?] for more 
  about
  that.

  The basic functionality can be extended using "plugins" (just 
  normal
  OCaml libraries). Plugins are available for interacting with 
  Docker,
  Git, GitHub and Slack. These are in separate packages
  (e.g. `current_github') to avoid having the base package pull in 
  too
  many dependencies).

  There is also an optional Cap'n Proto RPC interface, in the
  `current_rpc' opam package. This is used, for example, by 
  [citty] to
  provide a TTY interface to ocaml-ci.

  [The OCurrent wiki] contains examples, and documentation on the
  various plugins.

  Here's an example pipeline (from the base image builder):

  <https://roscidus.com/blog/images/cicd/docker-base-images-thumb.png>


[OCurrent] <https://github.com/ocurrent/ocurrent>

[ocaml-ci] <https://github.com/ocurrent/ocaml-ci/>

[docker-base-images] 
<https://github.com/ocurrent/docker-base-images>

[CI/CD Pipelines: Monad, Arrow or Dart?]
<https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/>

[citty] <https://github.com/ocurrent/citty>

[The OCurrent wiki] <https://github.com/ocurrent/ocurrent/wiki>


Anil Madhavapeddy then added
────────────────────────────

  For those curious about the relation to the existing CI used in
  opam-repository, then it is no coincidence that @talex5 is the 
  author
  of both :-)

  This DSL is the next iteration of the [datakit-ci], but 
  specialised to
  be faster and simpler for extending with OCaml and more complex
  workflows that our OCaml Platform tools need these days (like
  ocamlformat linting, or dune expect promotion, or odoc
  cross-referenced doc generation).  We are planning a smooth 
  migration
  next year over to the new system, but wanted to release this 
  early to
  show you some of the pieces going into this new iteration.  I am
  particularly excited about the new tty-based interface that 
  saves an
  awful lot of clicking around on web UIs for CI results…


[datakit-ci] <https://github.com/moby/datakit>


New pages for OCaml API
═══════════════════════

  Archive: 
  <https://discuss.ocaml.org/t/new-pages-for-ocaml-api/4720/13>


Continuing this thread, sanette announced
─────────────────────────────────────────

  I have uploaded a new version (same link
  <https://sanette.github.io/ocaml-api/>)
  • background color for links in the TOC @Maelan
  • more indentation for value descriptions @Maelan, @grayswandyr
  • word wrapping long `<pre>' codes @grayswandyr
  • type table: remove `(*' and `*)', give more space to code wrt
    comments, diminish comment's color @grayswandyr

  searching is not ready yet… please wait suggestions for dark 
  theme
  welcome


sanette later added
───────────────────

  I have just uploaded a new version with a basic search engine.
  • for each page, you can search values/modules
  • in the general index page, the search includes also the 
  descriptions
  • search results are ranked by relevance

  the downside is that each page now comes with an index of about 
  570Kb
  in the form of an index.js file. I'm kind of hoping that the 
  browser
  will cache this, but I'm not sure. It would be maybe better to 
  only
  load the index file on demand.


Irmin 2.0.0 release
═══════════════════

  Archive: 
  <https://discuss.ocaml.org/t/ann-irmin-2-0-0-release/4746/1>


Thomas Gazagnaire announced
───────────────────────────

  On behalf of the Irmin development team, I am very happy to 
  announce
  the release of Irmin 2.0.0, a major release of the Git-like
  distributed branching and storage substrate that underpins
  [MirageOS]. We began the release process for all the components 
  that
  make up Irmin [back in May 2019], and there have been close to 
  1000
  commits since Irmin 1.4.0 released back in June 2018. To 
  celebrate
  this milestone, we have a new logo and opened a dedicated 
  website:
  [irmin.org].

  More details here: 
  <https://tarides.com/blog/2019-11-21-irmin-v2>


[MirageOS] <https://mirage.io/>

[back in May 2019]
<https://tarides.com/blog/2019-05-13-on-the-road-to-irmin-v2>

[irmin.org] <https://irmin.org/>


Tail cascade: a new indentation style for some OCaml constructs
═══════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/tail-cascade-a-new-indentation-style-for-some-ocaml-constructs/4736/1>


gasche announced
────────────────

  I recently decided to change my indentation style for certain 
  OCaml
  constructs in a way that I'm going to describe below. I just 
  coined a
  name for this approach, "tail cascade". I'm creating this topic 
  to
  convince everyone that this is a cool idea you should adopt as
  well. Or at least tolerate it when you review other people's 
  code.


Problem
╌╌╌╌╌╌╌

  Programs that heavily use `match' often see a shift to the right 
  due
  to nested indentation.

  ┌────
  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │   match bar x with
  │   | FooBar -> ...
  │   | Blah y ->
  │     match f y with
  │     | Some z ->
  │       ...
  └────

  Another problem with this style is that it suffers from the 
  "dangling
  bar" issue: if you try to add a new case for one of the exterior
  `match', it is parsed as belonging to the innermost `match'. 
  People
  have been recommending (rightly) to use `begin match .. end' for 
  all
  nested match constructs to avoid this issue.

  ┌────
  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │   begin match bar x with
  │   | FooBar -> ...
  │   | Blah y ->
  │     begin match f y with
  │     | None -> ...
  │     | Some z ->
  │       ...
  │     end
  │   (* now this is safe *)
  │   | FooBlah -> ...
  │   end
  └────

  But still the unpleasant shift to the right remains.


Proposal: cascading tail case
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  We should in general use `begin match .. end' for nested 
  matches. But
  the "cascading tail case" proposal is to *not* do it for the 
  *last*
  case of the pattern-matching, and instead *de-indent* (dedent) 
  this
  last case – tail case.

  ┌────
  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │ match bar x with
  │ | FooBar -> ...
  │ | Blah y ->
  │ match f y with
  │ | None -> ...
  │ | Some z ->
  │ ...
  └────

  Note that with this indentation style, the "dangling match" 
  problem is
  also avoided: unlike with the original, non `end'-protected 
  program,
  the indentation makes it immediately obvious that any further 
  case
  will be attached to the innermost match, and not any of the 
  exterior
  ones.

  A program using this "cascading tail" approach should always use
  `begin match .. end' for nested matches, except for a nested 
  match
  returned within the last branch of an outer match, which can
  (optionally) be dedented instead.

  The choice to dedent the last case corresponds to encouraging a
  sequential reading of the program, where the other cases are
  "auxiliary cases" checked first and dispatched quickly, and the 
  last
  case is the "main part" where the "rest" of the logic of the 
  program
  lies. This pattern is typical of nested pattern-matching on the
  `option' or `result' type for example:

  ┌────
  │ match foo x with
  │ | Error err ->
  │   fail_foo_error err
  │ | Ok y ->
  │ match bar y with
  │ | Error err ->
  │   fail_bar_error err
  │ | Ok () ->
  │ ...
  └────

  Remark: it is *not* always the case that the `Error' constructor 
  is
  the auxiliary case, and the `Ok' constructor is the main case;
  sometimes we implement fallback logic like "if `foo' work then 
  we are
  good, but otherwise we have to do this and that", and the error 
  case
  is the most salient (and longer) part of the program logic. I 
  would
  recommend being mindful, when you write code, of whether there 
  is a
  most convincing way to "sequentialize" it (distinguish auxiliary 
  and
  main/tail case), and avoid using cascading tails when there is 
  no
  clear sequentialization choice.

  Remark: some cases of tail cascades can be linearized by using a 
  good
  definition of "bind" and a monadic style. This tends to be very
  limited however: it fixes one of the constructors to always be 
  the
  "tail" constructor (always `Some', always `Ok'), and it only 
  works
  when the handling of the other constructors is very homogeneous
  (typically: return directly). In real code, many situations 
  occur
  where the monadic style doesn't fit the problem, but tail 
  cascade does
  help writing a readable program.


Generalization: tail cascade
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  While I have never seen cascading tail cases in real-world OCaml 
  code
  before (I'm happy to be given pointers; I think that the idea is 
  not
  new, but I'm not aware of previous attempts to give it a catchy 
  name
  and spread the cascade love), this is in fact a new (to me) 
  instance
  of a common technique that is used for other OCaml constructs:

  ┌────
  │ if foo x then ...
  │ else if bar x then ...
  │ else ... (* this `tail else` was dedented *)
  │
  │ let x = foo in
  │ let y = bar in (* this `tail let` was dedented *)
  │ ...            (* and the rest as well *)
  │
  │ bind foo @@ fun x ->
  │ bind bar @@ fun y -> (* this "tail function body" was dedented 
  *)
  │ ...                  (* and the rest as well *)
  └────

  I would call "tail cascade" (or maybe: "cascading tail") the 
  idea of
  dedenting the "rest" of an OCaml expression (compared to a 
  strict
  tree-nesting-based approach) when it morally describes the 
  "rest" of
  the expression. I use the name "tail" because those expressions 
  are
  almost always in tail-position in the sense of tail-calls.

  This general approach legitimizes some styles that I have seen, 
  and
  sometimes used, in the wild, while at the same time considering 
  that I
  may have been doing something improper, for example:

  ┌────
  │ if foo then blah else
  │ ... (* dedented *)
  │
  │
  │ Fun.protect
  │   ~finally:(...)
  │ @@ fun () ->
  │ ... (* dedented *)
  │
  │
  │ try simple_approach with exn ->
  │ ... (* dedented *)
  │
  │
  │ 1 +
  │ 2 + (* dedented *)
  │ ... (* dedented *)
  └────

  Remark: after a `then' or `else', many people share the 
  reasonable
  view that any expression containing imperative constructs (`foo; 
  bar')
  should be enclosed in a `begin .. end' block to avoid
  surprising-precedence issue. Just as for nested `match', this
  recommendation should be lifted for "tail else" constructs.

  Remark: The last example is a case where the dedented 
  expressions are
  *not* in tail-position from a runtime-evaluation point of view. 
  I am
  not sure as whether the two notions should be made to coincide 
  more
  strongly, but in any case I'm not fond of the style in this 
  particular
  example, I prefer to move the infix operator to the beginning of 
  the
  next line instead, following a different style and 
  justification.

  The possibility this "cascading tail" style today crucially 
  relies on
  the nesting properties of open-ended syntactic constructs, 
  notably
  `let' (commonly cascaded), and now `match' and `if
  ... else'. Proposals to transition to a syntax where `match' and
  `else' are forced to take a closing marker are incompatible with 
  the
  cascading style. I have not made my mind on whether this should 
  be
  considered a blocker for those proposals, but at least it shows 
  that
  having the open-ended form available has value for certain 
  programs.


Louis Gesbert then said
───────────────────────

  @gasche I prototyped a dedicated option in `ocp-indent', if 
  you're
  interested in trying it out :)
  ┌────
  │ opam pin 
  git+https://github.com/OCamlPro/ocp-indent#match-tail-cascade
  │ echo "match_tail_cascade=true" >> ~/.ocp-indent
  └────


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 #1.1.2: Type: text/html, Size: 50844 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-12 13:21 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-11-12 13:21 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 2875 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of November 05 
to 12,
2019.

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

Mirage 3.7.1 released
Old CWN


Mirage 3.7.1 released
═════════════════════

  Archive: 
  <https://discuss.ocaml.org/t/mirage-3-7-1-released/4634/1>


Hannes Mehnert announced
────────────────────────

  MirageOS 3.7.1 is released to opam repository now.

  Breaking change:
  • The hooks previously defined in
    OS.Main.at_enter/at_enter_iter/at_exit/at_exit_iter are now 
    part of
    Mirage_runtime (only used by mirage-entropy)
    <https://github.com/mirage/mirage/pull/1010>

  Behaviour changes of MirageOS unikernels:
  • A unikernel now always calls the Mirage_runtime.at_exit 
  registered
    hooks – once a unikernel succesfully executed its `start' in
    `Lwt_main.run', `exit 0' is called to ensure this behaviour
    <https://github.com/mirage/mirage/pull/1011>
  • Top-level exceptions are no longer caught (there used to be in
    mirage-unix/mirage-xen/mirage-solo5 custom handlers). The 
    OCaml
    runtime prints the exception and backtrace on stdout and calls 
    exit
    2 (from 4.10.0, abort() will be called).

  Deprecations (being removed from Mirage 4.0)
  • All Mirage_YYY_lwt are deprecated, Mirage_YYY interfaces are 
  no
    longer astracted over 'a io and buffer. This reduces the 
    amount of
    opam packages - mirage-yyy-lwt are no longer part of the 
    release
    (each mirage-yyy package provides a Mirage_yyy_lwt module for
    backwards compatibility). Motivation was discussed in
    <https://github.com/mirage/mirage/issues/1004>
  • mirage-types and mirage-types-lwt are deprecated, please use 
  the
    Mirage_YYY signatures directly instead.

  Other observable changes
  • `mirage configure' now deletes all exising opam files

  Most reverse dependencies are already released to opam, have a 
  look at
  <https://github.com/mirage/mirage/issues/1012> for progress (and 
  the
  temporary <https://github.com/mirage/mirage-dev.git#easy> opam
  overlay).


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 #1.1.2: Type: text/html, Size: 13405 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-11-05  6:55 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-11-05  6:55 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 1700 bytes --]

Here is the latest OCaml Weekly News, for the week of October 29 
to
November 05, 2019.

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

vim-ocaml - new home
Old CWN


vim-ocaml - new home
════════════════════

  Archive: 
  <https://discuss.ocaml.org/t/ann-vim-ocaml-new-home/4615/1>


Rudi Grinberg announced
───────────────────────

  Dear Vim & Neovim users,

  I would like to announce that I've officially moved the 
  [vim-ocaml]
  repository under the control of the OCaml organization on
  github. Please direct your bug reports and pull requests to this
  repository. This move is done not because vim-ocaml is being
  neglected, on the contrary, there's an active team of 
  maintainers that
  recently expanded. I simply want to take this opportunity to 
  draw more
  Vim & Noevim users to this project, as I suspect many users 
  aren't
  aware of recent efforts.


[vim-ocaml] <https://github.com/ocaml/vim-ocaml>


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 #1.1.2: Type: text/html, Size: 11877 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-10-15  7:28 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-10-15  7:28 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 5627 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of October 08 
to 15,
2019.

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

capnp-rpc 0.4.0
Ocaml-protoc.plugin.1.0.0
Old CWN


capnp-rpc 0.4.0
═══════════════

  Archive: 
  <https://discuss.ocaml.org/t/ann-capnp-rpc-0-4-0/4524/1>


Thomas Leonard announced
────────────────────────

  I'm pleased to announce the release of [capnp-rpc 0.4.0], an 
  OCaml
  implementation of the Cap'n Proto RPC specification.

  If you haven't used the library before, please see the 
  [documentation
  and tutorial]. Cap'n Proto RPC aims to provide secure, 
  efficient,
  typed communications between multiple parties.

  This library is now being used to build [ocaml-ci], where it is 
  used
  for all communication between the web frontend and backend 
  services,
  and to provide a command-line client.


[capnp-rpc 0.4.0]
<https://github.com/mirage/capnp-rpc/releases/tag/v0.4.0>

[documentation and tutorial]
<https://github.com/mirage/capnp-rpc/blob/master/README.md>

[ocaml-ci] <https://github.com/ocaml-ci/ocaml-ci>

Main changes since v0.3
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Breaking changes:

  • Wrap errors with the ``Capnp' tag to make it easier to compose 
  with
    other types of error.

  • Prefix all command-line options with `capnp-'.
    e.g. `--listen-address' is now `--capnp-listen-address'.  The 
    old
    names were confusing for applications that supported other 
    protocols
    too (e.g. a web server).

  New features:

  • Add `Capability.with_ref' convenience function.  This 
  automatically
    calls `dec_ref' when done.

  • Add Unix `Cap_file' module to load and save `Sturdy_refs'.  In
    particular, this ensures that saved cap files get a mode of 
    `0o600',
    since they contain secrets.

  • Export cmdliner network address parsing.  This is useful if 
  you
    don't want to use the default option parsing.  For example, if 
    you
    want to make Cap'n Proto an optional feature of your program.

  • Upgrade from `uint' (which is deprecated) to the newer 
  `stdint'.
    The latest version of `uint' is just a wrapper around 
    `stdint', so
    this shouldn't break anything if you are using the latest 
    version.

  • Put cmdliner options in their own man-page section.  Use
    `Capnp_rpc_unix.manpage_capnp_options' to control where in 
    your
    man-page they appear.

  • Enable `SO_KEEPALIVE' for TCP connections.  For use with 
  Docker's
    libnetwork, try something like this in your `stack.yml':
    ┌────
    │ sysctls:
    │   - 'net.ipv4.tcp_keepalive_time=60'
    └────


Ocaml-protoc.plugin.1.0.0
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-1-0-0/4535/1>


Anders Fugmann announced
────────────────────────

  I'm happy to announce the second release of 
  [ocaml-protoc-plugin].

  Ocaml-protoc-plugin is a plugin to googles `protoc' compiler 
  which
  generates type idiomatic to ocaml from `.proto' files including 
  full
  compliant serialization and deserialization functions.


[ocaml-protoc-plugin] 
<https://github.com/issuu/ocaml-protoc-plugin>

Most noteworthy changes in this release:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Full proto2 support.
  • The list of dependencies has been slimmed way down, and now 
  only
    depends on `conf-protoc' (the `protoc' compiler and googles 
    *well
    known types*).
  • Buckescript support.
  • Added options to change the ocaml (type for scalar types (int, 
  int64
    or int32).

  Many thanks to Wojtek Czekalski for helping trimming 
  dependencies and
  for Buclescript support.


Full changelog:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Support enum aliasing
  • Avoid name clash with on 'name'
  • Fix code generation when argument contains a path
  • Refactor internal types to make serialization and 
  deserialization
    type spec symmetrical.
  • Optimize deserialization for messages with max_id < 1024
  • Don't depend on Base in runtime
  • Slim runtime dependencies: Remove need for base, ocplib-endian 
  and
    ppx_let
  • Honor [packed=…] flag.
  • Make fixed scalar types default to int32 and int64
  • Support proto2 specification
  • Add options to switch between int64|int32 and int
  • Fix name clash problem with special enum names
  • Refactor serialization and deserialization to simplify emitted 
  code
  • Eagerly evaluate serialization (for speed).


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 #1.1.2: Type: text/html, Size: 16446 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2019-09-03  7:35 Alan Schmitt
  0 siblings, 0 replies; 15+ messages in thread
From: Alan Schmitt @ 2019-09-03  7:35 UTC (permalink / raw)
  To: lwn, cwn, caml-list

[-- Attachment #1.1.1: Type: text/plain, Size: 1966 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of August 27 to
September 03, 2019.

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

Ocaml-multicore: report on a June 2018 development meeting in 
Paris
Interesting OCaml Articles
Old CWN


Ocaml-multicore: report on a June 2018 development meeting in 
Paris
═══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-multicore-report-on-a-june-2018-development-meeting-in-paris/2202/10>


Deep in this thread, sid announced
──────────────────────────────────

  As a small step towards multicore, its interesting to note that
  <https://github.com/ocaml/ocaml/pull/8713> just got merged to 
  master!


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/46>


Yotam Barnoy announced
──────────────────────

  <https://www.ocamlpro.com/2019/08/30/ocamlpros-compiler-team-work-update/>


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 #1.1.2: Type: text/html, Size: 12394 bytes --]

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-14 14:16 [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Alan Schmitt
  -- strict thread matches above, loose matches on Subject: below --
2020-02-18  8:18 Alan Schmitt
2020-02-04  8:47 Alan Schmitt
2020-01-28 10:53 Alan Schmitt
2020-01-21 14:08 Alan Schmitt
2020-01-07 13:43 Alan Schmitt
2019-12-31  9:18 Alan Schmitt
2019-12-17  8:52 Alan Schmitt
2019-12-10  8:21 Alan Schmitt
2019-12-03 15:42 Alan Schmitt
2019-11-26  8:33 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-05  6:55 Alan Schmitt
2019-10-15  7:28 Alan Schmitt
2019-09-03  7:35 Alan Schmitt

caml-list - the Caml user's mailing list

Archives are clonable:
	git clone --mirror http://inbox.vuxu.org/caml-list
	git clone --mirror https://inbox.ocaml.org/caml-list

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.caml-list


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git