solidity library namespace conflicts

[ancjf]

I would like to use solidity as a library for aleth, but there are namespace conflicts, who can help me solve this problem?

[bshastry]

@ancjf could you please tell us how we can reproduce the namespace conflict you are facing? Could you also share the solidity contract that results in namespace conflicts?

[ekpyron]

Well, aleth and solidity used to be part of the same code base (if I remember my history lessons correctly ;-)), so they share the same namespaces, but have diverged a lot since then. We did talk about renaming the namespaces already, but I don't think we ever arrived at a decision - @christianparpart Do I remember correctly that you suggested that?

[Relabeling as "to discuss"]

[ekpyron]

I'm voting for reorganizing our namespace schema, but we need to come up with a nice schema, of course.

[bshastry]

Ah, I misunderstood this issue as namespace conflicts within solidity contracts :) Now I realize this issue refers to C++ namespace conflicts between the aleth and solidity projects

[chriseth]

@ancjf can you tell us a bit more about your use-case? We do not make any promises regarding the "linker interface" of Solidity, but maybe we could identify an interface that would work for you.

[ekpyron]

Call decision: we want to go ahead with reorganizing the namespaces and @christianparpart will write up a concrete proposal for it.

[ancjf]

Thank you for everybody prompt response. This improvement will greatly promote my work.

[christianparpart]

Without going too much into subjective opinions, I try to propose something that is as reusable as possible, and still makes sense semantically, and in a way that people won't dislike using those namespaces:

Assuming we're only touching the Solidity project (not Aleth), we have the following libraries (or sub systems)

| directory | description | old namespace | proposal 1|
|-------------|---------------------------------------------------------|----------|--------------------|
| libdevcore | some utility / helper functions used here and there | dev | solutil |
| libevmasm | EVM target machine API | dev::eth | soleth |
| liblangutil | Language utility APIs (language independant, almost at least) | langutil | langutil |
| libyul | Yul Language Frontend | yul | yul |
| libsolidity | Solidity Language Frontend | dev::solidity | solidity |
| liblll | LLL Language Frontend | dev::lll | lll |

There are two possibilities:

1. Continue eliminating the root namespace, and renaming libdevcore into libsolutil (just a name proposal) and give it the more distinct non-aleth-conflicting namespace solutil - and because eth is also too generic for libevmasm, I'd propose namespace soleth (or solevm); or
2. we create a team root namespace (such as "solidity") and place everything underneath. That might be convenient when having included the whole toolchain as a library in other projects.

@ekpyron What do you think?

[ekpyron]

@christianparpart Let's talk about it in the next meeting. I'm really not sure myself - I always found it strange to say that liblangutil is supposed to be language independent, even though it contains EVMVersion and even worse the token list (you can't get much more language specific than that...)...

Should we even reuse the same token list for yul as we currently do? Actually that doesn't make any sense to me... Maybe we should think about making liblangutil really language independent, e.g. by templateizing over the Tokens and moving EVMVersion to libevmasm, where it fits much better? And use a separate token list for yul?

Actually I would like having a top-level root namespace called solidity, but then again not for yul... so maybe three top-level ones? One for solidity, one for yul and one for stuff shared by both (which will be the hardest to name, but maybe langutil would be fine? I.e. making the other util and evmasm ones sub-namespaces of that one?)
Or maybe having everything in top-level solidity would be just as fine... I don't know, I was never good at naming things.

[christianparpart]

@ekpyron it is meant to be language independant, but I had to take _some_ trade-offs when moving things around (back then). Same applies to Scanner, that sadly contains solidity-related tokens / lexical grammar (it could be isolated, though, I didn't want to overdo it when I touched it some long time ago); if you find a better place for those two classes, I'm all in (they're needed for more than libsolidity).

[chriseth]

I would prefer fewer top-level namespaces. If the main goal is to stay compatible with other projects, I would also not oppose to a top-level solidity namespace and everything (even yul) below it.

[ekpyron]

I don't have hard opinions on this, but at the moment I lean towards either of the following two options:

Three top-level ones: solutil (or a better name), solidity and yul, where solutil is everything shared between solidity and yul.

Or one top-level one: solidity or maybe only sol and actually the same three sub-namepaces only that solutil should then just be util.

I think libdevcore and liblangutil could be merged as @axic suggested on gitter.
evmasm we could for now keep as top-level- or second-level-one, but I think we could actually distribute it to stuff specific to the evm backend of yul (somewhere under the yul namespace) and sol-evm compilation (somewhere under the "inner" solidity namespace - this would probably then depend on the yul backend specific part, but that's fine).

But I'm fine with any other schema as well.

[axic]

I'm pretty much in favour of a single top-level namespace, solidity, which reflects the project name.

[christianparpart]

Hm, do we still want other projects to make use of Yul (also in terms of our source code?), in that case, I'd suggest in not embedding the yul api into the root level namespace. @chriseth @axic.

[chriseth]

I think solidity::yul can still be argued, since it is not a standalone implementation.

[ekpyron]

I'd say solidity::yul may even be better than plain yul - in theory there could be several implementations of Yul and you might want to have them both in one project, e.g. to check their equivalence (not sure that's likely to ever happen, but still). And people can still make yul an alias to solidity::yul themselves, if they want.

[christianparpart]

So what about this:

solidity            - root namespace
solidity::util      - language-independant utility functions (old devcore)
solidity::langutil  - language-dependant utility API (such as old langutil)
solidity::evmasm    - current libevmasm, just inside root namespace (maybe later merged into yul/backend/evm?)
solidity::yul       - yul API
solidity::frontend  - language frontend (including analysis and codegen)

Of course, one may want to merge language dependant langutil with language independant util (ex-libdevcore). I don't care too much, except that I feel a little bit more cleaner when there is a line between them :).

[ekpyron]

@christianparpart Yes, that looks good to me for now and we can think about whether to merge stuff or move stuff around on top of this later - no reason to do everything in one step. If anybody has a better name than solidity::lang that'd be nice, but I myself would be fine with it as well.

[chriseth]

Can the "to discuss" label be removed?