General Unsolved Issues

[gingerBill]

This is a list of the general unsolved problems that Odin has yet to "solve":

Modules

• How should modules/packages/libraries be handled?
• Should it just be based around the file (like at the moment) or should it be based around the directory?
• Are there any good and simple examples that another languages implement?

Odin uses a Modula/Go approach to packages.

"Generics"

• Should Odin have some form of parametric polymorphism for types and procedures?
• Would a form of "semantic macros" for code generation be better?

Odin now support parametric polymorphic for procedures and structs.

Metaprogramming

• How much metaprogramming should be in the language?
• Compile Time Execution?
• AST Modification?
• Compiler Plugin System?

Debugging

• Debug Information generation for the LLVM backend is needed Nearly finished for LLVM

Language Functionality

• Inline assembly

Backend

• Custom SSA
• Custom code generation
• Built in linker rather than relying on a third party linker

Note: This list may be appended to.

[MuradMathematics]

Odin seems to be a great project for a new programming language, but keep in mind what you really want this language to be - a modern all-round replacement for C. I don't want to say that something is wrong, so far it looks great, but I fear that this language will overshoot its objective by far and ultimately drift into complexity. If I want to program in a complex language I don't have to look far there are many languages availabe (just take a peek at Nim, you said it yourself: it is also a great project but in terms of simplicity - no, it is basically C++ with syntax sugar now). For instance, 80% of the time you will use either a variable, an array or a struct in C - that's about it. And that is why so many people still use C to this day, it is just made so simple. There is even a way of programming called "orthodox C++" that suggests to combine C with operator overloading, namespaces and other basic C++ features, and not more. Most of the time when a language has certain "features" they do not only vanish inside a big documentation but also confuse aspiring learners with new and unusual syntax that differs from, lets say, simple variable assignment (basic blocks of the language). Simplicity is the highest form of sophistication. That being said I really appreciate your effort to ask the community - this is a true mindset for an open source project. Concerning your questions I would dislike Generics or (as a programmer who basically only programs in C, Delphi and Python) simply don't use them. As far as modules go, I would prefer C style loading (file based). It looks like Nim has a decent way of doing this (which is simple and cocncise):

Nim supports splitting a program into pieces with a module concept. Each module is in its own file. Modules enable information hiding and separate compilation. A module may gain access to the symbols of another module by using the import statement.

and

The include statement does something fundamentally different than importing a module: it merely includes the contents of a file. The include statement is useful to split up a large module into several files.

Just like in C when we have a stdlibraries.h header somewhere, that itself includes all the C stdlibs so we don't have to include each of them seperately for every file.

[hazeycode]

Compile Time Execution is right at the top of my wish-list!

[gingerBill]

@MuradTroll

I fear that this language will overshoot its objective by far and ultimately drift into complexity

There is very little chance of that happening. One of the striving goals has been simplicity. I am known for removing features rather than adding them. I haven’t even added the compile time execution because I am not sure where it is needed as it is a huge complexity for the language. (Not necessarily in implementation but in understanding)

As for modules, I have settled on the Modula/Go approach with packages. This is the best compromise between simplicity, organisation, consistent linking names, and namespaces. I have done huge amounts of experimentation between file based libraries and directory based libraries and they both have their advantages and disadvantages but I found that the directory based approach had the better trade offs.

Odin does have a form of parametric polymorphism (generics) but it is limited and simple by design. It’s necessarily for some certain things as macros are not available.

Niklaus Wirth has been my idol through the design of Odin. I am a huge fan of Pascal and the family because of its simplicity and well thought out design decisions. There is a lot of embedded knowledge in those languages that many modern languages do not know about or ignore.

Sorry this is a late reply. I did not know this comment existed until now 5 months later.

[hazeycode]

@gingerBill

I haven’t even added the compile time execution because I am not sure where it is needed as it is a huge complexity for the language. (Not necessarily in implementation but in understanding)

It would be useful for running expensive routines offline, such as generating lookup tables or "cooking" assets for the target platform, without requiring external tooling/scripts and wrangling their output. With the asset cooking case specifically, I might want to be able to switch between compile time and run time execution depending on whether I am building a development or release build. For development I likely want to cook assets on the fly and hot reload them but for release I want to define my entire build pipeline in one language. What's the current state and problems to be solved with this?

[gingerBill]

@hazeycode One of the issues with compile time execution (CTE) is determinism. I want Odin to be as deterministic as possible. Things will be executed in the same order every time.

Another is that adding CTE is requiring that the compiler has a VM that can also run external code without a problem. This can be difficult to do and complicates the compiler a lot. When the custom backend is in place, running the intermediate "bytecode" through a custom VM may be very well possible.

Another issue is making sure that the VM can act like the target/host machine and work as expected. This is not as easy as you expect.

Adding CTE is not at all simple if you want it to work properly. It may feel like a "simple" feature to use but that does not mean it is at all simple in conjunction with everything else.