[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Jun 8 05:37:35 PDT 2021
Hello
Here is the latest OCaml Weekly News, for the week of June 01 to 08,
2021.
Table of Contents
─────────────────
Boltzgen a test generator for teachers
Benchmark Tooling Engineer Position
Lightweight OCaml Docker Images created by dune with Multi-Stage Builds
Runtime Systems Engineer, OCaml Labs (UK) / Tarides (FR) / Segfault Systems (IN) / Remote
Timedesc 0.4.0 - date time handling library
serialization of closures
OCaml compiler development newsletter, issue 2: May 2021
OCaml 4.13.0, first alpha release
Spin 0.8.0
vec 0.3.0
First release of line_oriented
Old CWN
Boltzgen a test generator for teachers
══════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/boltzgen-a-test-generator-for-teachers/7944/1>
benoitbarbot announced
──────────────────────
Boltzgen a test generator for teachers.
I am pleased to introduce <https://git.lacl.fr/barbot/boltzgen>;
Boltzgen: Boltzmann sampler test generator is a tool to generate
tests. Given a function signature it generates a random set of call of
this function on generated random input. Inputs are generated using a
Boltzmann sampler for unlabeled structure. This project has the
following objectives:
• The primary goal was developing automatic grading system for purely
functional programming exercises.
• Generate values with as little information as possible in most case
only its type, the input by the user should be as small as possible;
• Strong probabilistic guarantee on the uniformity of the sample
process thanks to Boltzmann sampler theory.
Given a function specification as a type signature :
┌────
│ type 'a tree = Empty | Node of 'a tree * 'a * 'a tree
│ val sum: int list tree -> int
└────
Boltzgen returns calls to this function :
┌────
│ sum (Node((Empty,[],(Node((Empty,[(-4); (-2); 6],Empty))))))
│ sum (Node(((Node((Empty,[],Empty))),[13],Empty)))
│ sum (Node(((Node((Empty,[57],Empty))),[],(Node((Empty,[],(Node((Empty,[],(Node((Empty,[],Empty))))))))))))
│ ...
└────
You can try it with a buggy web interface here
<https://www.lacl.fr/~barbot/boltzgen/>. Or install it with opam and
test locally.
This tool was quickly developed during the first COVID 19 lockdown to
quickly generate tests for programming exercise, many bugs remains,
comments and contributions are welcome.
Perry E. Metzger asked and benoitbarbot replied
───────────────────────────────────────────────
Is there a reason that the utility of such a tool should
be restricted to teachers? Property based randomized test
systems also need tools like this for real world testing
systems, do they not?
No, they should not be restricted to teachers, There are some tool in
Haskell using the same technique for test generations.
<https://hackage.haskell.org/package/boltzmann-samplers>
But this utility in particular was built with teaching and automatic
grading in mind. When teaching the base of functional programming,
most exercises are writing a well define standalone pure function.
When writing real world code, you often (depending on programming
style) have a mutable custom type and function which interact with
this type (ex HashTbl). Generating good test in this setting require
additional work (but I have a few ideas).
For this tool additional developments are required to use it in a
testing framework :
• The tool was written in hast, it probably should be entirely
rewritten.
• Make it more reliable, right now I look at the generated result to
make sure everything went right, more users are required !
• It should be integrated in a testing framework which requires, I
think, moving the generation at compile time and not at the
execution time, for each type several functions are generated, this
generation should be done with ppx_deriving, I need help to do that.
• The ToDo list should be emptied, in particular I need help for the
runtime generation of Ocaml value which requires knowledge in the
internal Ocaml representation of value.
The theory of Boltzmann sampling is really beautiful in the fact that
abstract math (namely formal power series) are used in practice to
generate quite efficiently discrete value. I believe it could be used
for efficient testing in general.
Benchmark Tooling Engineer Position
═══════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/benchmark-tooling-engineer-position/7955/1>
Celine announced
────────────────
[Tarides] is looking for a [Benchmark Tooling Engineer].
Tarides is a tech start-up founded in Paris in 2018 by pioneers of
programming languages and cloud computing. Tarides develops a software
infrastructure platform to deploy secure, distributed applications
with strict resource constraints and low-latency performance
requirements. Today, Tarides is composed of a diverse team of 35+
people.
We welcome applications from people of all backgrounds. We strive to
create a representative, inclusive and friendly team, because we know
that different experiences, perspectives and backgrounds make for a
better workplace.
Please, don’t hesitate to contact me if you have any question, I’ll be
more than happy to reply! :slight_smile:
[Tarides] <https://tarides.com/>
[Benchmark Tooling Engineer]
<https://tarides.com/jobs/benchmark-tooling-engineer>
Lightweight OCaml Docker Images created by dune with Multi-Stage Builds
═══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/lightweight-ocaml-docker-images-created-by-dune-with-multi-stage-builds/7958/1>
Asya-kawai announced
────────────────────
I've written an article of Docker multi-stage Build for lightweight
OCaml application using dune. I refered this
article(<https://discuss.ocaml.org/t/lightweight-ocaml-docker-images-with-multi-stage-builds/804>)
and customized to use dune.
<https://github.com/Asya-kawai/blog/blob/main/20210603/how-to-create-minimum-ocaml-docker-image-en.md>
Yawar Amin then said
────────────────────
Nice write-up! You can also use opam lockfiles for reproducible
builds: <https://khady.info/opam-sandbox.html>
The main difference in the Dockerfile will be:
┌────
│ opam install . --deps-only --locked
└────
You won't need to specify the packages in the install command, since
they will be in the lockfile.
Runtime Systems Engineer, OCaml Labs (UK) / Tarides (FR) / Segfault Systems (IN) / Remote
═════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/runtime-systems-engineer-ocaml-labs-uk-tarides-fr-segfault-systems-in-remote/7959/1>
KC Sivaramakrishnan announced
─────────────────────────────
Multicore OCaml Runtime Systems Engineer
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The Multicore OCaml team is hiring a runtime systems engineer to hack
on the OCaml compiler. This position is being advertised jointly by
[OCaml Labs (UK)], [Tarides (France)] and [Segfault Systems (India)].
[OCaml Labs (UK)] <https://ocamllabs.io/runtime_systems_engineer.html>
[Tarides (France)] <https://tarides.com/jobs/runtime-systems-engineer>
[Segfault Systems (India)]
<https://segfault.systems/runtime_systems_engineer.html>
Multicore OCaml
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
The [Multicore OCaml] project aims to bring native support for
scalable concurrency and shared memory parallelism to the OCaml
programming language. At its core, Multicore OCaml extends OCaml with
[effect handlers] for expressing scalable concurrency, and a
[high-performance concurrent garbage collector] aimed at responsive
networked applications. Multicore OCaml is also the first
industrial-strength language to be equipped with [an efficient yet
modular memory model], allowing high-level local program reasoning
while retaining performance. Multicore OCaml is actively being
developed and core features are being [upstreamed to OCaml].
[Multicore OCaml] <https://github.com/ocaml-multicore>
[effect handlers] <https://arxiv.org/abs/2104.00250>
[high-performance concurrent garbage collector]
<https://arxiv.org/abs/2004.11663>
[an efficient yet modular memory model]
<https://kcsrk.info/papers/pldi18-memory.pdf>
[upstreamed to OCaml]
<https://github.com/ocaml/ocaml/pulls?q=label%3Amulticore-prerequisite+>
Qualifications & Experience
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We are looking for an experienced (3Y+) systems engineer to join our
team. Ideally, you will have:
• Excellent knowledge of C programming, parallel programming and
Operating Systems.
• Worked on Compilers, Garbage Collectors and other runtime systems.
• Working knowledge of computer architecture and micro-architecture.
• Experience in analysing benchmarks and application performance.
• Track record of building production-quality software.
• Demonstrable open source contributions are a plus, but not required.
• Good communication skills in English; English is the corporate
language.
• Experience of working in multidisciplinary teams.
Responsibilities
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Design and implement features in the Multicore OCaml runtime system.
• Develop tests and documentation for the Multicore OCaml features.
• Implement parallel benchmarks, analyse and improve the performance
of Multicore OCaml programs.
• Submit pull requests to the OCaml programming language on GitHub,
and work with the OCaml core team to get the features merged.
• Work with external clients and other teams to gather requirements,
develop proposals, design solutions and communicate project
statuses.
• Provide technical mentorship to other developers on the team.
• Communicate with the wider open-source community (discuss, blog
posts, meetups, conferences, talks, etc.).
What we offer
╌╌╌╌╌╌╌╌╌╌╌╌╌
• Competitive pay and benefits package.
• Flexible working hours and the possibility to work remotely within
the UK / France / India.
• Supportive team environment with experienced Technical and Team
Leads.
• The opportunity to grow with a fast-growing company.
Apply
╌╌╌╌╌
• *OCaml Labs (UK)*: Please send your CV and cover letter to
*jobs at ocamllabs.io*.
• *Tarides (France)*: Please send your CV and cover letter to
*apply at tarides.com*.
• *Segfault Systems (India)*: Please send your CV and cover letter to
*jobs at segfault.systems*.
If shortlisted, you will have three online interviews starting with a
general interview, followed by a technical interview, and finally an
interview with the team.
We welcome applications from people of all backgrounds. We strive to
create a representative, inclusive and friendly team because we know
that different experiences, perspectives and backgrounds make for a
better workplace.
Timedesc 0.4.0 - date time handling library
═══════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-timedesc-0-4-0-date-time-handling-library/7962/1>
Darren announced
────────────────
I'm pleased to announce the release of [Timedesc] 0.4.0.
Timedesc provides utilities to describe points of time, and properly
handle calendar and time zone information.
Tutorial and API doc can be found [here].
[Timedesc] <https://github.com/daypack-dev/timere>
[here]
<https://daypack-dev.github.io/timere/timedesc/Timedesc/index.html>
Features
╌╌╌╌╌╌╌╌
• Timestamp and date time handling with platform independent time zone
support
• Subset of the IANA time zone database is built into this library
• Supports Gregorian calendar date, ISO week date, and ISO ordinal
date
• Supports nanosecond precision
• ISO8601 parsing and RFC3339 printing
Major changes since 0.1.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Added `ceil', `floor', and `round' to `Timedesc.Span'
• Better support for second fraction for non-RFC3339 pretty printers
• This includes automatic deduction of smallest number of fractional
digits required for lossless representation, previously only used
for RFC3339 pretty printers (see `{sec-frac:c}' [description])
• Added `Timedesc.Zoneless' module for better time zone-less date time
support
• Added `compare_chrono_min', `compare_chrono_max', and
`compare_struct' for comparing `Timedesc.t' values
[description]
<https://daypack-dev.github.io/timere/timedesc/Timedesc/index.html#pretty-printing>
serialization of closures
═════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2021-06/msg00003.html>
Christophe Raffalli asked
─────────────────────────
I just noticed that in 4.12+effect, in the road to multicore, we have
now the nice exception:
┌────
│ Failure("Serializing closures is broken in multicore")
└────
This is a bit a pity: if you want to use both multicore and
multi-machine parallelism, then, marshalling closures was useful for
communication between machines in some cases. Is it a final decision
or serialization of closures will be lost forever in OCaml ?
Remark: Closures is not marked as obsolete in Marshal.mli
Xavier Leroy replied
────────────────────
I was not aware of this limitation of Multicore OCaml, and looking at
its git history, it looks like it was introduced very early in the
development, perhaps to make things simpler initially.
Marshalling of function closures has always been sort of experimental
and not super reliable, but I was not expecting it to be incompatible
with Multicore OCaml. We (the core dev team) will sort it out.
OCaml compiler development newsletter, issue 2: May 2021
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-2-may-2021/7965/1>
gasche announced
────────────────
I’m happy to publish the second issue of the “OCaml compiler
development newsletter”. (This is by no means exhaustive: many people
didn’t end up having the time to write something, and it’s fine.)
Feel free of course to comment or ask questions!
If you have been working on the OCaml compiler and want to say
something, please feel free to post in this thread! If you would like
me to get in touch next time I prepare a newsletter issue (some random
point in the future), please let me know by email at (gabriel.scherer
at gmail).
Previous issue:
• [OCaml compiler development newsletter, issue 1: before May 2021]
[OCaml compiler development newsletter, issue 1: before May 2021]
<https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-1-before-may-2021/7831>
Gabriel Scherer and Nicolas Chataing (@gasche and @nchataing)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
[Gabriel writing] my main recent compiler-related activity is ongoing
work with my intern Nicolas Chataing to implement a prototype of
variant constructor unboxing, a core subset of what Jeremy Yallop
proposed ( <https://github.com/ocaml/RFCs/pull/14> ). Currently OCaml
can "unbox" a variant if it has a single constructor (with a single
parameter),
┌────
│ type t = Int of int [@@unboxed]
└────
Jeremy's idea is to support the case where there are other
constructors, but the tag (immediate value or block constructor tag)
of the constructor parameter is disjoint from the tag of any other
value at this type.
┌────
│ type t = Short of int [@unboxed] | Long of Mpz.t
└────
Nicolas' prototype implementation is going along nicely, with some
interesting challenges encountered and solved, and a few refactoring
PRs along the way (#[10307], #[10412], #[10428]).
A key ingredient is to be able to compute the "head shape" of an OCaml
type, an over-approximation of the set of possible tags of its
values. We hit a few engineering and research issues in doing
this. Where in the codebase should this be computed (beware of
circular module dependencies)? Can we compute this information in a
precise way in presence of mutually-recursive types, without risking
non-termination?
We are taking inspiration from a general approach proposed by Leo
White and Stephen Dolan to compute these kind of "type declaration
properties" on-demand instead of as part of the type declaration's
signature (see their proposal for "immediacy" at #[10017], #[10041] ),
but our property is demanded more often (any occurrence of the
constructor) and is more fine-grained (it is sensitive to type
parameters), so we had to invent some solutions for new problems. (A
close cousin is `get_unboxed_type_representation', which avoids
non-termination by using fuel, and we wanted something nicer than
that.)
We discuss our handling of termination in (some) details in the
following short abstract: [Unfolding ML datatype definitions without
loops].
[10307] <https://github.com/ocaml/ocaml/issues/10307>
[10412] <https://github.com/ocaml/ocaml/issues/10412>
[10428] <https://github.com/ocaml/ocaml/issues/10428>
[10017] <https://github.com/ocaml/ocaml/pull/10017>
[10041] <https://github.com/ocaml/ocaml/pull/10041>
[Unfolding ML datatype definitions without loops]
<http://gallium.inria.fr/~scherer/research/constructor-unboxing/constructor-unboxing-ml-workshop-2021.pdf>
Xavier Leroy (@xavierleroy)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I worked with Damien Doligez and Sadiq Jaffer on the "safe points"
proposal (#[10039]), which is required to move forward with
integrating Multicore OCaml. I re-expressed the static analyses that
support the insertion of polls as backward dataflow analyses, making
them simpler to understand and more robust. We also discussed whether
to insert polls at the top of loops or at the bottom. Both strategies
are implemented in the current state of the PR, and Sadiq is currently
benchmarking them.
All this rekindled my interest in dataflow analyses. I wrote a
generic backward dataflow analyzer, parameterized by an abstract
domain and a transfer function (#[10404]). Originally I intended to
use it only for the insertion of polls, but I also used it to
reimplement the liveness analysis that plays a crucial role for
register allocation and dead code elimination. A problem with the old
liveness analysis is that it takes time exponential in the nesting of
loops. The new generic analyzer avoids this pitfall by starting
fixpoint iterations not systematically at the bottom of the abstract
domain, but at the fixpoint found earlier, if any. This makes
liveness analysis linear in the nesting of loops, and at worst cubic
in the size of the function, instead of exponential.
Then I applied the same trick to the two passes that insert spills and
reloads preventively (#[10414]). These are "analyze and
simultaneously transform" passes, so I could not use the generic
dataflow analyzer, but I could reuse the same improved fixpoint
iteration strategy, again avoiding behaviors exponential in the
nesting of loops. For instance, a trivial function consisting of 16
nested "for" loops now compiles in a few milliseconds, while it took
several seconds before.
[10039] <https://github.com/ocaml/ocaml/issues/10039>
[10404] <https://github.com/ocaml/ocaml/issues/10404>
[10414] <https://github.com/ocaml/ocaml/issues/10414>
Jacques Garrigue (@garrigue)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
No new PR this month, but I have kept working on those that were
started in April, and are not yet merged:
• #[10348] improves the way expansion is done during unification, to
avoid some spurious GADT related ambiguity errors
• #[10364] changes the typing of the body of the cases of
pattern-matchings, allowing to warn in some non-principal
situations; it also uncovered a number of principality related bugs
inside the the type-checker
• #[10337] enforces that one always manipulate a normalized view of
types by making type_expr an abstract type (with Takafumi Saikawa
(@t6s))
For this last PR, we have interestingly observed that while this
multiplied the number of calls to repr by a factor of up to 4,
resulting in a 4% overhead in stdlib for instance, we could see no
performance degradation in the compilation of Coq.
I have also discovered a new principality bug in the implementation of
GADTs (see #[10348] again), which fortunately should not affect
soundness.
In a slightly different direction, I have started working on a backend
targetting Coq: <https://github.com/COCTI/ocaml/tree/ocaml_in_coq>
If you add the -coq option to ocamlc, you get a .v file in place of a
.cmo. It is still in a very early stage, only able to compile core ML
programs, including references. The main difference with coq-of-ocaml
is that the translation is intended to be soundness preserving: the
resulting Coq code can be typed and evaluated without axioms, and
should reduce to the same resut as the source program, so that the
type soudness of Coq underwrites that of ocaml (for individual
programs). At this point, it only relies on a single relaxation of the
positivity restriction of Coq.
[10348] <https://github.com/ocaml/ocaml/issues/10348>
[10364] <https://github.com/ocaml/ocaml/issues/10364>
[10337] <https://github.com/ocaml/ocaml/issues/10337>
Thomas Refis (@trefis)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Recently, Didier Rémy and I have been looking at _modular explicits_,
a small extension between the core and module language to help
manipulate first-class functors and give the illusion of abstraction
over module arguments in the core language via a new construct
(tentatively) called _dependent functions_.
This construct was first introduced in the context of the [modular
implicits] proposal; roughly it's what you're left with if you take
away the "resolution of implicit arguments" part of that proposal.
As such, it is a natural stepping stone towards modular implicits and
already has its own self-contained PR: #[9187], contributed by Matthew
Ryan.
What Didier and I have been focusing on recently is producing a more
formal description of the feature and its relationship to first-class
modules, as well as some arguments to justify that it is reasonable
and desirable to add it to the language, even in the absence of
modular implicits.
[modular implicits] <https://arxiv.org/pdf/1512.01895.pdf>
[9187] <https://github.com/ocaml/ocaml/pull/9187>
Stephen Dolan (@stedolan)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
I've just opened #[10437], which allows explicit quantifiers for type
variables in signatures and GADTs, a small feature I promised to OCaml
maintainers a dozen of months ago. (The ulterior motive is that these
explicit quantifiers give a good place to put layout information, but
I think they're worth having on their own merits).
Note: The on-demand immediacy proposal in #[10017] / #[10041], which
Gabriel mentioned above, is extracted from part of the kinding system
in the experimental branch
<https://github.com/janestreet/ocaml/tree/layouts> , which
additionally allows quantification over types of a given immediacy /
layout: for instance, one can write `type ('a : immediate) t = { foo :
'a }' and have inference, etc. work as expected.
[10437] <https://github.com/ocaml/ocaml/pull/10437>
[10017] <https://github.com/ocaml/ocaml/issues/10017>
[10041] <https://github.com/ocaml/ocaml/issues/10041>
Sadiq Jaffer (@sadiqj)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The Safepoints PR #[10039] has a few updates. It now has a new static
analysis, written by Xavier Leroy and Damien Doligez, and has working
code emitters on all 64-bit platforms.
The static analysis had some flexibility on poll placement in
loops. We've benchmarked on amd64 and arm64, choosing to go with the
option that results in slightly fewer instructions and branches across
the Sandmark suite. Short of some refactoring I don't think there are
any other oustanding issues with the PR.
Building on safepoints, I should soon have an attribute to propose
which will enable users with atomic code blocks to safely migrate to a
version of OCaml with safepoints. A draft PR or RFC will be coming
very soon.
I am also doing some work on the [instrumented runtime]. One of the
project's goals is to be able to continuously monitor OCaml
applications running in a production environment. To that end I'm
evaluating the instrumented runtime's performance overhead (both
enabled and not), determining what work would be required to reduced
the overhead and how we could modify the runtime to continuously
extract metrics and events.
[10039] <https://github.com/ocaml/ocaml/pull/10039/>
[instrumented runtime]
<https://ocaml.org/releases/4.12/manual/instrumented-runtime.html>
Anil Madhavapeddy (@avsm)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Ewan Mellor and I are working on a CI that'll make it easy to test
individual changesets to the OCaml compiler and run "reverse
dependencies" against a set of opam packages to isolate precisely
what's causing a failure.
A failure to build an opam package can come from a variety of
reasons. This can range from a build failure against a stable released
compiler, to a failure on just OCaml trunk (but success on a released
compiler), to a failure just on OCaml trunk + the PR in question.
It's the triage of which of these situations is causing the package
build failure that our new CI focusses on. Having this CI should let
us quickly determine a PR's impact and potential regressions on the
package ecosystem. Once the CI is stable on the OCaml multicore trees,
I plan to submit it as a CI to run against mainline OCaml as well.
The working tree is at [ocaml-multicore-ci] (although it's called a
"multicore CI", its really just turned into an "ocaml-compiler-ci" and
we will rename the repository before a first release).
[ocaml-multicore-ci] <https://github.com/ocurrent/ocaml-multicore-ci>
Florian Angeletti (@Octachron)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This week I have been working a bit on adding swaps and moves to the
diffing based error messages for type declarations in #[10361].
(And the release of the first alpha for OCaml 4.13.0)
The core idea of the PR is that when comparing
┌────
│ type t = { a:int; b:int; c:int; d:int }
└────
with
┌────
│ type t = { a:int; c:int; d:int }
└────
in an error message, it is better to notice that we are missing one
field rather than trying to compare the fields `b' and `c'.
And with the machinery introduced for functor diffing, this is quite
straigthforward to implement. I have been experimenting with this
option since last december, and with the functor diffing PR merged
#[9331], I proposed a PR #[10361] in April.
However, compared to functors, in type declarations, we have have one
supplementary piece of information: the name of fields and
constructors at a given position. Not using this piece of information
yields slightly akward error messages:
┌────
│ module M: sig type t = { a:int; b:int } end = struct type t = {b:int; a:int} end
└────
┌────
│ 1. Fields have different names, a and b.
│ 2. Fields have different names, b and a.
└────
Here, it would be better to recognize that the two fields have been
swapped.
One simple way to do this without increasing the diffing complexity is
to identify swaps at posteriori on the optimal patch produced by the
diffing algorithm.
In this way we can replace the previous error message by
┌────
│ 1<->2. Fields a and b have been swapped.
└────
without increasing the cost of the error analysis.
A similar situation happens when the position of a field changes
between the interface and the implementation
┌────
│ module M: sig
│ type t = { a:unit; b:int; c:float}
│ end = struct
│ type t = { b:int; c:float; a:unit}
│ end
└────
Explaining that the implementation can be transformed into the
interface by adding a field `a' before the field `b' and deleting
another field `a' after `c' is correct. But it is much nicer to sum up
the issue as
┌────
│ 1->3. Field a has been moved from position 1 to 3
└────
Both composite moves are now recognized.
People interested by error message in OCaml should also have a look at
the great work by Antal Spector-Zabusky in #[10407] to improve the
module level error message by expanding them with a full error trace.
(The two PRs are quite complementary.)
[10361] <https://github.com/ocaml/ocaml/pull/10361>
[9331] <https://github.com/ocaml/ocaml/issues/9331>
[10361] <https://github.com/ocaml/ocaml/issues/10361>
[10407] <https://github.com/ocaml/ocaml/pull/10407>
Frédéric Recoules asked and gasche replied
──────────────────────────────────────────
Thank you @gasche and all the authors, these posts are
really interesting!
I am looking forward to see all of this in the compiler,
especially the work of @nchataing :upside_down_face:
Just reacting to the example, it would be nice if you can
tag the type `Mpz.t' with `[@custom]' + `[@unboxed]' (is
there a syntax to add multiple annotation?) because
`custom' (hat, c.f. [Unfolding ML datatype definitions
without loops] is distinguishable of `int' (hat and all
other tag too).
One issue with `custom' tags is that they are currently only visible
on the C side, the OCaml type is opaque, so the `[@custom]' annotation
would have to be trusted by the compiler, which is meh. But the
feature would be a special case of allowing shape restrictions on
abstract types; which makes perfect sense.
[Unfolding ML datatype definitions without loops]
<http://gallium.inria.fr/~scherer/research/constructor-unboxing/constructor-unboxing-ml-workshop-2021.pdf>
Rudi Grinberg asked and octachron replied
─────────────────────────────────────────
@octachron the progress in improving error messages is an
exciting development. Thanks!
Is there any work to improve error messages for
consumption by other tools? I know there's the json
effort, but it seems to have been stalled. What about
improving the compiler api to use the `sub' field for sub
messages more consistently. This would greatly improve the
presentation of errors to the user in lsp/merlin.
The json work for the error metadata was temporally stopped to ensure
that it was still compatible with Merlin, but I am planning to get
back to in for 4.14 . Also I would be quite keen to discuss potential
use cases to ensure that the produced json is useful for tools.
Concerning, error submessages, I didn't know that lsp/merlin was using
them successfully. But yes, if there is such an use case, it would
help motivate a more consistent use of submessages in the
compiler. Note that as an experiment, the new functor diffing error
message in 4.13.0 already uses suberror messages in the functor
application case. However, for functors (and any module level error
really), a tree structure would have been more natural than a list of
submessages at least from the producer side. I would expect that tools
could also benefit from such a tree of error messages, but this seems
worth discussing in term of design.
Rudi Grinberg then said
───────────────────────
A tree structure sounds like the right thing to do conceptually. But
at least in lsp, errors are permitted to have a flat list of "related"
messages with locations. That fits the current data error data
structure used by OCaml. If a tree was used, I would probably have to
flatten it anyways.
OCaml 4.13.0, first alpha release
═════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-4-13-0-first-alpha-release/7967/1>
octachron announced
───────────────────
Three months after the release of OCaml 4.12.0, the set of new
features for the future version 4.13.0 of OCaml has been frozen. I am
thus happy to announce the first alpha release for OCaml 4.13.0 .
This alpha version is here to help fellow hackers join us early in our
bug hunting and opam ecosystem fixing fun (see below for the
installation instructions). You can see the progress on this front at
<https://github.com/ocaml/opam-repository/issues/18791>
If you find any bugs, please report them here:
<https://github.com/ocaml/ocaml/issues>
Once most major OCaml tools are supported, we will switch to beta
releases. The full release is expected to happen in September.
If you are interested by the ongoing list of new features and bug
fixes, the updated change log for OCaml 4.13.0 is available at:
<https://github.com/ocaml/ocaml/blob/4.13/Changes>
Note that there is still some on-going work to support improved
polling points in preparation for OCaml multicore. Another alpha
release will be published once this work is merged.
Installation instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The base compiler can be installed as an opam switch with the
following commands
┌────
│ opam update
│ opam switch create 4.13.0~alpha1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
If you want to tweak the configuration of the compiler, you can switch
to the option variant with:
┌────
│ opam update
│ opam switch create <switch_name> --packages=ocaml-variants.4.13.0~alpha1+options,<option_list>
│ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
where <option_list> is a comma separated list of ocaml-option-*
packages. For instance, for a flambda and no-flat-float-array switch:
┌────
│ opam switch create 4.13.0~alpha1+flambda+nffa
│ --packages=ocaml-variants.4.13.0~alpha1+options,ocaml-option-flambda,ocaml-option-no-flat-float-array
│ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
└────
All available options can be listed with "opam search ocaml-option".
If you want to test this version, it is advised to install the alpha
opam repository at
<https://github.com/kit-ty-kate/opam-alpha-repository>
with
┌────
│ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
└────
This alpha repository contains various fixes in the process of being
upstreamed.
The source code for the alpha is also available at these addresses:
• <https://github.com/ocaml/ocaml/archive/4.13.0-alpha1.tar.gz>
• <https://caml.inria.fr/pub/distrib/ocaml-4.13/ocaml-4.13.0~alpha1.tar.gz>
Spin 0.8.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-spin-0-8-0/7969/1>
Thibaut Mattio announced
────────────────────────
I'm happy to announce a new version of `Spin', the OCaml project
generator.
This version comes with a lot of improvements. I'm joining the
Changelog below, but I'll highlight some of them here.
Spin as an Opam plugin
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This version of Spin is available as an Opam plugin.
`opam spin new cli', for instance, will generate a new CLI.
The `hello' command
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
This release comes with a brand new template targetted solely at
first-time users.
The `spin hello' command will generate an hello world project where
the development setup and directory structure are explained in the
README.
Each file are extensively documented, so users can just open any file
and learn by example.
If you're onboarding new users, I'd be curious what's your experience
with `opam spin hello'!
Simplified templates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The templates have been simplified.
Some templates supported some very specific use cases, such as
deploying a CLI on NPM. This is no longer the case and the focus for
the official templates from now on will be to support the recommended
setup (ie. the OCaml Platform) only.
Part of this simplification is also achieved by dropping the support
for Reason and Esy. The previous templates will be available at
(<https://github.com/ocaml-templates>) with the `reason-' prefix.
I've extracted them already, but they will need some reworking before
they are usable again.
Better prompts
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The interactive prompts have been improved through a complete rewrite
of [`inquire'], the prompt library used in Spin.
I've tried to test the new prompts as much as possible, but if you
encounter an issue with them, don't hesitate to open an issue on Spin
or Inquire.
[`inquire'] <https://github.com/tmattio/inquire>
Dream template
╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Not really part of this release, because this is a community template,
but I have been working on a template for Dream, the new kid OCaml web
framework scene, by @aantron.
To try it, you can run: `opam spin new
https://github.com/ocaml-templates/spin-dream'.
It comes with a modern setup, including:
• TailwindCSS integrated with Dune
• Inter fonts
• Live reloading on file system change
• Turbolink setup
It's a bit heavy for my taste at the moment, so I will work on making
most of the features optionnal, but if you're looking to start a new
Dream app quickly, this might be useful.
Changelog
╌╌╌╌╌╌╌╌╌
Here's the complete Changelog.
Added
┄┄┄┄┄
• Added an `hello' command to generate a tutorial project
• Added a `parse_binaries' stanza that can be `true' to force Spin to
parse binary files
• Added a `raw_files' stanza that takes a list of file or glob
expressions to instruct Spin to copy files instead of parsing them
• Added a new `c-bindings' template for C bindings using `ctypes'
• Added a new `js' template for javascript applications with
`js_of_ocaml'
Changed
┄┄┄┄┄┄┄
• Removed the `gen' subcommand. The generators will come back with a
much better workflow
• Dropped support for Esy and Reason. The templates are now using the
recommended OCaml setup only. The previous templates are hosted at
<https://github.com/ocaml-templates/>
• Changed the templates to use the `ISC' license
• Increase version of `ocamlformat' to `0.18.0' in templates
• Do not install merlin when installing dev dependencies in templates
• Drop support for BuckleScript in PPX
• Drop support for publishing on NPM for CLI and PPX templates
• Update CI scripts to `ocaml/setup-ocaml at v2'
• Remove python dependency to serve documentation in Makefile
• Inline release script in Makefile
• Remove global `-open StdLabels' in templates
• The `spa' template has been removed from the official templates and
now lives at <https://github.com/ocaml-templates/spin-incr-dom>
• Spin does not parse binary files by default anymore, they are simply
copied to the destination folder
• Use `test' stanza for unit tests now that Alcotest prints colors by
default
• Remove unused flags defined in the root's `dune' file
Fixes
┄┄┄┄┄
• The project generation will now fail before the configurations
prompt if the output directory is not empty
• By default, Spin now creates a local switch for the generated
projects. This can be changed with `spin config', or by setting the
env variable `SPIN_CREATE_SWITCH=false'
• Fix an CLI incompatibility between `opam.2.0.X' and `opam.2.1.X'
that made Spin unusable with the former.
I'm also taking the occasion to mention that I am looking for a
co-maintainer. If you're interested in improving OCaml tooling and
think Spin is a good addition to OCamlers' toolchain, please DM me :)
vec 0.3.0
═════════
Archive: <https://discuss.ocaml.org/t/ann-vec-0-3-0/7971/1>
Alex Ionescu announced
──────────────────────
I’ve just released version `0.3.0' of `vec' , a library for safe
dynamic arrays with Rust-like mutability permissions.
You can find the package on opam [here], and the source repository
[here].
Based on recent feedback, I've revised the API to have more consistent
permissions, following some simple rules:
• *Reading* basic properties (`length', `capacity', `growth_rate')
requires no permissions
• Operations that return or indirectly give access to the vector's
elements (i.e. by passing them to a user-provided function) require
*read* permission
• Operations that mutate the vector's state (including modifying its
elements, resizing its buffer or modifying growth rate) require
*write* permission
I've also added some new APIs for inserting and removing elements at
arbitrary indexes, and reworked how `ensure_capacity' works: Now
`ensure_capacity n v' ensures that `v''s buffer has at least `n' free
slots.
Please let me know if you have any feedback or suggestions!
[here] <https://opam.ocaml.org/packages/vec/>
[here] <https://github.com/aionescu/vec>
First release of line_oriented
══════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-line-oriented/7977/1>
UnixJunkie announced
────────────────────
A very small library to treat files with lines of text like string
lists. <https://github.com/UnixJunkie/line-oriented>
The interface is here:
<https://github.com/UnixJunkie/line-oriented/blob/main/src/line_oriented.mli>
To get it:
┌────
│ opam install line_oriented
└────
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 at polytechnique.org>
[the archive] <https://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <https://alan.petitepomme.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20210608/9ec3e81f/attachment-0001.html>
More information about the caml-news-weekly
mailing list