I've just been working on a standalone file. Let's call it project.nim. Compiles and runs no problem. However, when I adapted the code to make it a bit more compact and saved the leaner version as project-wee.nim it refuses to compile with:
$ nim c -r project-wee.nim
Hint: used config file '/usr/local/Cellar/nim/0.19.4/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Error: invalid module name: project-wee
I've seen this error referenced here: https://forum.nim-lang.org/t/1541 but the poster there was told it was because his source file had dots in the name. Is it also not allowed to have hyphens in the filename?
"A valid module name can only be a valid Nim identifier (and thus its filename is identifier.nim)."
And hyphens are not allowed in identifiers.
Thanks all.
Neither Python, C or C++ allow hyphens in filenames AFAIK.
Python certainly does. The project in question was one of my old Python scripts I'm trying to rewrite, while learning Nim. And the original project-wee.py file runs fine.
Technically, yes: __import__('foo-bar')
But it's almost certainly not considered good style. And I don't think I've ever seen it done in practice. For example, where I work, in a large codebase that uses hyphen-delimited filenames for C++ code, my team breaks that convention to use underscore_delimited filenames for python code for this reason.
`foo-bar` Saying you would recommend against use without saying why you would and then saying that alone is a good enough reason is not much of an argument, actually.
So, why would you recommend against its usage? Kebab-case is quite popular for program names in the Unix world. Fully 20% of my /usr/bin programs have a '-' in them (about 3X the number that use underscore). (These are not programs named by me.) Also popular is having the name of the program match the name of the source file up to an extension. So, if you mean to say this 75% super majority of dash vs underscore program namers is so wrong-headed, what exactly have they got wrong?
As for "dealing with code" that uses it, use in library/module names as opposed to program names is unlikely to be common. That said, tossing backticks on there doesn't sound very much of a burden..It might be less onerous in some more system-wide sense than having a "library version" and a "program version" or symlinks or other kinds of aliasing some people might concoct to work around the problem.
I think having a {.out:.} pragma to let a program set its own (default, overridable on the nim c command-line) name is a good step, too. That might solve most people's problems. It would still seem lamely inflexible that module names are more restricted than other identifier names (procs, vars, etc.).
It's also quite common to use hyphens in project names, git repositories and project home pages - including many projects in Nimble.
Being able to keep consistent naming across project name, filenames, executable name and imports instead of a random mixture of "my-project" "my_project" and "myproject" would make Nim more friendly.