Comment author: @xavierleroy

" Doctor, it hurts when I do this!

• Then don't do it."

If you feel strongly about this, we could probably use '$' instead of '__' as the module separator. '$' followed by an integer (ASCII code) is used in code emitters to encode infix symbols, but I think no conflict is possible there. However, some ports (PPC) use '.' instead of '$' for the latter purpose, and I'm not sure why. Could this indicate that some assemblers do not support '$' in symbols?

Comment author: @xavierleroy

Of course, '.' as module separator would be uber cool, but again I'm unsure about support by various assemblers (MASM?)

Comment author: @alainfrisch

What about using _ as the module separator, escaping _ into __ inside names ?

Comment author: @damiendoligez

I don't think this problem is pressing enough to justify mangling user idents.

Comment author: @mshinwell

Also, Flambda cannot cope with this situation (#7349 and "A question about the semantics of -for-pack" on caml-devel). It was suggested that perhaps there should be a proper error in this situation, since it causes a fatal error with Flambda.

Comment author: @alainfrisch

What do you mean by "this situation"? Here, this is not about linking directly module compiled with -pack. The problem is the same if the module "U" in the PR description is -packed into a module X and this X is linked together with X__U. The problem here is not related to module clashes, but to the internal convention used by -pack to avoid symbol conflicts.

Comment author: @mshinwell

Ah yes, I misread this one.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

As far as I know, this is not restricted to packs, defining a submodule U in a regular file x.ml will generate symbols that may clash with symbols in x__U.ml (at least with flambda, I don't remember what closure generates in this case).
I think this issue should be kept open, as a reminder that we may want to choose a new separator in symbols that is not allowed in identifiers, but it is very low priority.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.