Hmm. I thought the example you gave worked now, actually.

I would like to see Set, Map and Tbl, so in favour.

That seems like an anti-pattern: you're adding dependencies between modules in the stdlib, which we probably want to avoid in general, forcing (IIUC) more things to get linked whenever someone uses String.

We had been using this pattern extensively in core for a long time, and have now been moving away from it in our new libraries (e.g. Base).
I'm no expert on the matter, so I'll let @diml comment, but, offhand, it feels like a bad move.

I'm not sure on the scale of the stdlib that there is any real problem with dependencies here.

The alternative is presumably to adopt the Base-style approach within Set and Map, right? That's presumably rather more work, although I'm unsure how much exactly.

FWIW that's something I end up doing consistently in any non-library project, but I agree with @trefis it may not be a great idea in certain settings.

But then if you have #608 that may not matter, I'd be curious if js_of_ocaml would actually strip them if unused.

I'm not sure on the scale of the stdlib that there is any real problem with dependencies here.

Well, I suspect that with that way of thinking it might actually become a problem at some point, at which point you've already lost.

The alternative is presumably ...

... to do nothing?

But then if you have #608 that may not matter

That's a pretty big if.

If there are people willing to work on this, doing nothing isn't really a good option. There is clear value in having the standard library provide basic data structures over basic types, without having to clutter up user code instantiating them, and with consistent easily-discoverable naming provided. These structures should fit within a framework such that in a typical program the majority---if not all---types can be equipped with them and satisfy standard interfaces. (The same goes for printing functions.)

It really is very convenient when you can just say X.Set.add or X.print or whatever (using the appropriate notation), for all of your "X"s: and it leads to better code. Particularly for sets and maps, I think they should often be used more, but tend not to be---at least without libraries such as Base---since they are not immediately at hand.

As far as the implementation goes, @sliquister is probably the expert on this, but from what I remember we didn't really have any problem with the submodule approach until our tree scaled up to be at a very large scale. I don't think it should be dismissed outright.

If we're concerned about creating inter-dependencies, perhaps another module e.g. Data could be used, that stores the relation between the types: Data.String.Map, Data.Int.Set etc.

(Data.String.Map sounds like a sensible idea to me, although I don't know about the new module name.)

(Data.String.Map sounds like a sensible idea to me, although I don't know about the new module name.)

I don't like this idea. I often find that beyond two module levels code readability suffers. Both because of the resulting length of identifiers which hinders writing compact code (by which I mean sequences of let one-liners) and from the visual noise introduced by too many dotted levels.

And of course you could not open such a module as it would override String... that is unless you call these module say String_{set,map} which is a bit meh or if you include String in those but frankly at that point I rather inverse the idea and have a Bare.{String,...} to open and the full glory in the base String.

Somehow the String module is the natural place where you'd like to have them.

If we want to avoid linking too much, how about defining a module CamlinternalString with

module Map = Map.Make (struct type t = string let compare = compare end)
module Set = Set.Make (struct type t = string let compare = compare end)

and then in string.ml,

module Set = CamlinternalString.Set
module Map = CamlinternalString.Map

Then, if I understand module aliases correctly, linking with String will not pull in Set and Map unless actually used.

@dbuenzli Wouldn't this hypothetical Data module used like
MoreLabels is?

There isn't clear agreement on this PR, so closing.