[ANN] containers 2.0+alpha1

Community
, ,
1

Dear camel riders,

I have the pleasure to announce that containers 2.0+alpha1 is being released.

containers is a modular, lightweight, and performant extension of the standard library. Version 2.0 introduces a monomorphic mode (thanks to @jpdeplaix) that is designed to prevent errors caused by the polymorphic “magic” operators such as (=). This breaking release is also the occasion to switch to dune, and to fix some inconsistencies in the API (mostly printers).

If you use containers, please give a try to 2.0+alpha1 and report any issue on the bucktracker!

tag: https://github.com/c-cube/ocaml-containers/releases/tag/2.0%2Balpha1
changelog: https://github.com/c-cube/ocaml-containers/blob/2.0%2Balpha1/CHANGELOG.adoc

8 Likes
2

opam suggests the new alpha version for an automatic upgrade of containers. is this intended? (rather than only testing with explicit opam pin for now?)

3

i tried a bit of updating of a project to 2.0. the monomorphic equality change requires some adjustments in quite a few places. i would do them for current projects but probably not for old projects. what’s a good way to keep old projects working without too much overhead when i need to go back to them in the future?

a brute-force solution would be a new package name containers2 but that seems like overkill. maybe there is some other way for me to keep my old projects working?

4

I think you can open Pervasives after opening Containers to void the monomorphic shadowing, at least for a start.

5

would that still keep e.g. CCList shadowing List from the stdlib?

6

You should try it, but I believe so.

7

Hi,
as far as I’m concerned, I had a bunch of fixes to make but that’s OK, and it’s indeed better anyway.

Now = is to be replaced by a given equal but AFAICT there is no replacement for <> other than not @@ equal, or is there? No nequal?

8

as far as I’m concerned, I had a bunch of fixes to make but that’s OK,
and it’s indeed better anyway.

Cool! @jpdeplaix is the one to thank for this, really.

Now = is to be replaced by a given equal but AFAICT there is no
replacement for <> other than not @@ equal, or is there? No
nequal

Not really. It’s a bit inconvenient but it’s harder to have combinators for nequal, I think.

9

Personally, I always forget whether the negation of = is <> or !=, so I prefer to use not, that way I’m sure, ^^

10

Well I don’t forget it, I don’t even think about it and it’s true I found a few != here and there in some code I wrote with colleagues. I didn’t git blame to see who was to be shouted at :slight_smile:
But here all polymorphic operators are hidden so this not @@ ... precaution would not necessarily be needed any more.
Of course, writing combinators for negated functions is a problem.

11

This mostly works. I do

open Containers
open! Pervasives

The code changes still required for containers1 code are those for the labeled equality or comparison arguments in some functions. So even when foregoing the monomorphic operators, some manual work is still required in each source file to make a containers1 codebase work on containers2.

1 Like
12

How should someone pin the alpha version? Clone and pin the local one, or can it be pinned on a URL?

13

The alpha version is available through opam.
Just do opam upgrade containers if no installed packages rely on containers1.
Otherwise you will need to either install it on a new switch or remove/fix the packages that need containers1.

1 Like