@dsrw > You could have a macro that took a filename as a parameter, read the file, > ran it through a parser of some sort, then used the parse tree to generate > Nim code which would be compiled into your program.
Awesome, it means that Nim is a language with almost infinite possibilities. > It would be a lot more work than just making a DSL with Nim syntax, but it's > an option if you need it. As Araq says though, Nim syntax is really flexible. > The Nim code you pass to a macro doesn't need to mean anything to the > compiler, it just needs to be parsable. That means that it's still whitespace > sensitive, blocks still have to start with :, your braces have to match up > and things of that nature, but apart from the basic structural elements the > code can be whatever you like. > > Writing your DSL in Nim syntax and reading it with a macro has a lot of > advantages. You don't have to write a parser. The elements of your parse tree > all have line/file info associated with them, making it fairly easy to > surface useful errors. You get lots of tools for easily transversing and > searching your tree, and enforcing certain conditions about the code that's > passed in. And you only have to fiddle with the bits that you actually care > about. If you want to handle some constructs as normal Nim code you can just > pass them along untouched, and the Nim compiler will do all the work. It was a question about Nim's extensibility because I'm young and I'm choosing a definitive language for all my projects, I'm not the kind of person that creates projects in multiple languages, maybe someday I create my own toy language as a macro in Nim and use for my possible needs. Having Nim the possibility of creating sub-languages is something awesome to me. And about Nim'm syntax, is just perfect for me that have been studying Python for my personal needs. > Nim is definitely the closest thing to a universal language that I've found. > There are things that it isn't particularly good at, but that's mostly due to > a lack of libraries/ecosystem rather than a fundamental limitation of the > language. One of my primary uses of Nim is as a super simple, logo inspired > language to teach kids to code. The code doesn't look much like normal Nim. > It has a completely different way to define functions, eschews immutability, > makes many things global by default, and has custom syntax for drawing things > and making simple behaviours. It runs in an interpreter (the NimVM, what Nim > normally uses to evaluate macros and config files), makes everything > reloadable on the fly, and doesn't even follow the normal Nim style > conventions. It's probably the furthest thing from what Araq intended when he > started writing Nim, but yet Nim is a great fit. I'm almost positive that I > would have abandoned my project ages ago if I had started in any other > language. Now that I just know that Nim is so expansible I can say the same: An universal language. It's a pitty that some big company/big tech like Mozilla doesn't support Nim team, Rust crates have 95000+ packages and Nimble 2000+, I hope someday the Nim count grows very much. * * * I can say that I'm falling in love with Nim after reading all the answer in this topic, I realized that Nim is that universal language I always dream to. I hope that in 2~3 years I can make my projects, modules, macros and extensions and help Nim grow. Somethings I'm going to prioritize is Linux namespaces handling and low-level network stuff like manipulating TUN/TAP devices. Maybe in the future I can have an idea of a large project to write in Nim. Thank all of you for the answers, @Araq and @dsrw; I'm sure in 50 years I will still remember this topic and this conversation. รต/
