Include name collision avoidence

[Woccz]

I think, similar to Python, when a library is included, all of its macros should have to be called with myLib.myMacro(x).

Further, from "myLib" include myMacro functionality, like Python, could be added, which imports a single macro from the given library, while being able to use myMacro(x), rather than using myLib.myMacro(x).

Thirdly, again like Python, an as keyword could be added to avoid naming collisions, include "myLib" as aLibrary, or from "myLib" include myMacro as aMacro.
These would then be usable as aLibrary.myMacro(x) and aMacro(x) respectively.

Of course, this is not a pressing issue, but if it is not too difficult to implement, I believe it would be helpful for code and collision management.
This would, for example, allow the "std/math" macros to be simply be defined as their macro names, and included as math.<macro name>, for example, math_floor could be implemented as

macro floor(x) expr
    ...
end

and be called with math.floor(x), or simply floor(x) if included with from "std/math" include floor

Thank you.

[dbaumgarten]

While that's absolutely a reasonable suggestion, it would make the whole include-logic a lot more complicated.
I was just to lazy to do it "properly" ^^.
Also while that's simple and logical for macros and definitions, it could feel strange for included code that is not part of a macro.

Namespaced imports will come somewhen in the future. But currently there is simply not enough includable-code to cause major collision-issues and the "filename_"-convention works good enough.

Therefore: backlog

[Woccz]

Yes, definitely a backlog change.

Thank you.