3 ms·

This is a really interesting project and I like where you're taking it. I've played with Nim for a number of years, and I really like the no-runtime aspect of

This is a really interesting project and I like where you're taking it. I've played with Nim for a number of years, and I really like the no-runtime aspect of Muon and the flexibility and simplicity that you've created with it. Unlike many others in this thread, I like the whitespace decisions you've made, though I go in the opposite direction - have you thought about making braces optional? Your roadmap looks great as well. Have you considered any of the following?: - Lisp-style Macros (e.g. Macros as functions that transform an AST object) -- this would also answer many of the preprocessor questions you had, especially if you can specify compile-time behavior (like in zig) - Github-based decentralized package management system - Owned pointers memory management options

nickmqb 8y ago
Thanks! I don't think we should lose the braces. Braces help avoid mistakes when refactoring/copying/pasting code, and they make the language look more familiar to people coming from C-like languages, which I think are large enough advantages to justify having them. I'm considering adding some meta-programming/reflection capabilities in some form, if they don't increase the complexity of the language too much. Lisp-style macros would be a possible approach, compiler plugins would be another. The latter approach might be easier to implement though. A package manager will be out of scope for at least the near future, but long term it would be great to have one! Re: owned pointers. I'd recommend that people look into more coarse grained memory management strategies first (e.g. arena allocation), and use one of those if possible. However, these strategies definitely have their limitations, which is where alternatives like owned/shared pointers could come in. However, to implement a "proper" owned pointer, e.g. an alternative to std::unique_ptr<T>, we would need destructors (which Muon will never implement) and move semantics (of which there is a chance that Muon _might_ implement it, but probably not anytime soon). With move semantics we can perhaps create a lighter weight owned pointer that is still useful; I'll have to experiment a bit to see how that would work out.

nickmqb 8y ago

Thanks! I don't think we should lose the braces. Braces help avoid mistakes when refactoring/copying/pasting code, and they make the language look more familiar to people coming from C-like languages, which I think are large enough advantages to justify having them. I'm considering adding some meta-programming/reflection capabilities in some form, if they don't increase the complexity of the language too much. Lisp-style macros would be a possible approach, compiler plugins would be another. The latter approach might be easier to implement though. A package manager will be out of scope for at least the near future, but long term it would be great to have one! Re: owned pointers. I'd recommend that people look into more coarse grained memory management strategies first (e.g. arena allocation), and use one of those if possible. However, these strategies definitely have their limitations, which is where alternatives like owned/shared pointers could come in. However, to implement a "proper" owned pointer, e.g. an alternative to std::unique_ptr<T>, we would need destructors (which Muon will never implement) and move semantics (of which there is a chance that Muon _might_ implement it, but probably not anytime soon). With move semantics we can perhaps create a lighter weight owned pointer that is still useful; I'll have to experiment a bit to see how that would work out.