Re: [RFC] Namespaces in OLANG

[Johnny Richard <johnny@johnnyrichard.com>]

Thank you very much for providing this insightful reading material.

Although I've appended a few comments, I'm hesitant to make significant
decisions at this early stage of language development due to my limited
expertise. However, if you're confident in the direction proposed, I
won't obstruct progress.

On Sat, Mar 23, 2024 at 11:46:46PM -0300, Carlos Maniero wrote:
> Using namespaces in olang
> -------------------------
> 
> Before we begin, I want to ensure that we’re all on the same page regarding the
> following points:
> 
> 1. Deterministic Code Generation: Our goal is to be able to examine an olang
> function and precisely predict the assembly code that will be generated.
> 
> 2. Full Compatibility with C: We aim for seamless integration with C. We don’t
> want to introduce features to the language solely for compatibility with C. Any
> code compiled by olang should be usable in C without requiring any additional
> boilerplate.
> 
> 3. Manual namespacing is inconvenient: While it’s possible to create a manual
> namespace for your functions in C by prefixing them with a namespace, this
> approach can be cumbersome and inconvenient.
> 
> To address conflicts while still ensuring predictable code generation,
> compatibility with C and without the need for manual namespaces, I purpose the
> *ns* statement.
> 
>   ns olang.core.math
> 
>   fn add(a: u32, b: u32): u32 {
>     return a + b
>   }
> 
> This could generate an assembly label called *olang_core_math__add*. Let's
> evaluate this solution against our three key criteria:
> 
> 1. Deterministic Code Generation:
>    It is deterministic! The function label is always {ns}__{fn_name}.
> 
> 2. Full Compatibility with C:
> 
>    It is completely compatible with C!
> 
>      int olang_core_math__add(int, int);
> 
>    If you think it is ugly to call a function that way directly, you can create
>    macros in C to improve the readability, but completely optional.
> 
>      #define NSMATH(name) olang_core_math__##name

I think this is too ugly and very hack.  I would prefer to call
olang_core_math_add instead.

> 3. Manual namespacing is inconvenient: 
> 
>    You don't need to manually namespace every function with the cost of start
>    every single file with a *ns* statement.

If we keep managing names manually, we already have the *1* and *2* for
free.  So, the only benefit of namespacing would be to avoid the
inconvenience of adding it manually.

> An important observation of the *ns* usage is that it must match the directory
> structure. The path of a file that declares the namespace *olang.core.math*
> must ends with *olang/core/math.ol*. This requirement is need for future
> import resolution.
> 
> Alternatives:
> -------------
> 
> 1. Automatically create namespaces based on the filename:

I know we don't have written down nicely the goal of the language, but I
prefer being explicit and avoid convention over configuration.

> 2. Manual namespaces: ...
> 
> Conclusion
> ----------
> 
> In my opinion, the introduction of a namespace statement offers numerous
> benefits:
> 
> - It aids in resolving function name conflicts.
> - It facilitates deterministic code generation while maintaining compatibility
>   with C.

The current suggestion doesn't solve the all compatibility with C.  We
have to provide a way of calling a C function from olang code without
namespacing (in case of namespace being mandatory).

> - It simplifies the resolution of imports.

I would suggest to not go much further with import resolution (unless
you already want to define modules).  Perhaps we could have namespace
doing nothing else than namespacing...

> These advantages come with the minor stipulation of initiating all files with a
> namespace statement, which, in my view, is a small price to pay for the
> benefits gained.

I'm not keen on the idea of enforcing strict adherence to the folder
structure.

How about we introduce a namespace block instead? Within this
block, everything would automatically have the namespace added as a
prefix. This could offer more flexibility while still maintaining
organization.

> Note that *ns* is just a suggestion, we can go with *module* or any other
> keyword. I don't know if we have plans to have C++ like namespaces which is a
> totally different thing.

I think module has a different meaning.  If you want to have modules, for
sure we have to discuss import resolution.  IMHO namespace shouldn't do
anything else than namespacing.

> Also I started to think about it because I'm working in adding debugging
> information on the code we generate and I have the need to represent a d file
> in the AST and the program node does not seems appropriated for it.

Today we can use the "new" <translation-unit> as the main entrypoint for
a source file. 

Could we use this AST node to attach the file path to it?  Or even
better, is there a way of embed the .ol file into the ELF binary?