And I like short extensions because they are highly redundant and it looks strange to see .c .h .cpp .png .jpeg .nim .txt .rst .doc .md .nimscript and I liked .nims btw. I do not see how that is not clearly something else than .nim .. it is a char longer

It would be cool if, by convention, nim knew that if you typed in "nim default" and there is a nimscript in there with the name 'default', it would run that script. Then you could do something like "make all", but instead "nim all"

I also am fine with 'nims' instead of 'nimscript', but dont have a strong preference.

What is the relationship between this and the (now discontinued) nim secret?

Of course they share the VM - if I understand correctly in both cases a VM is instantiated by the compiler and some modules are preloaded.

Would it be possible to use this approach to embed an interpreter into a Nim application? It would be especially nice if one could use this to have a sandboxed interpreter that can only import whitelisted modules.

Importing a few modules, such as os, from the interpreter does not work right now, but am I right to assume that they would work if they were statically preloaded while instantiating the VM?

This looks pretty cool. I'm on vacation so I can't give it a try thus don't have much to comment on this yet. I must say however that I also liked .nims better than .nimscript as the extension for nim scripts.
2015-08-18 08:00:52

nim secret is based on the same codebase but it is a REPL and as such it's harder to test and to ensure that things are still going well after the user made an error. Also it made a very bad first expression to all the people who would start the REPL to learn Nim. So, bugfixes for NimScript improve nim secret too as a nice side-effect but that doesn't mean I'm keen on reviving nim secret.

Would it be possible to use this approach to embed an interpreter into a Nim application? It would be especially nice if one could use this to have a sandboxed interpreter that can only import whitelisted modules.

Yes it is a sandboxed interpreter, but as I said a REPL is much more work than an interpreter.

Importing a few modules, such as os, from the interpreter does not work right now, but am I right to assume that they would work if they were statically preloaded while instantiating the VM?

Exactly, but the complexity of "preloading" a whole module is high. But I will make math and os work with Nimscript.

With all the people chiming in for .nims, I just wanted to throw in my vote for .nimscript on the primary reason that is 2015

Seriously, 'nimscript' is much better at self describing the file and works pretty well with tab completion too (people should try that sometime . I'm not quite sure why people want to abbreviate this - it's not that long. I believe it is best to call one thing by one name and use the same name as much as possible - the compiler stuff and documentation all use 'nimscript' so why not the same for the extension? This is a small example, but aliasing concepts is unnecessary cognitive load.