@ and "" don't have to actually differ from nil, it could be an implementation detail. Pretty much like option[ref T not nil] can be implemented as ref T.
Yep. And that's how it will be done.
- nim program.nim should behave like nim c -r program.nim, instead of giving an error. This would give the user a feeling of "it just works", instead of having to read the man page.
- nimcache should not be visible. It should be renamed .nimcache and should start hidden.
- The binaries should be created inside .nimcache if the user used nim program.nim or nim -r program.nim. The binaries should be visible at current working directory only when the user explicitly asks for them using nim c program.nim.
The proposed changes are meant to make the experience of the beginner programmer easier and less surprising. This isn't to make the experience of the advanced programmer any harder. The current behavior could just be a few flags away.
That are very subjective recommendations, with some disadvantages.
"nim program" as a default alias for "nim c -r program.nim" with hidden executable would mean that program is compiled again and again for each execution -- until user discovers that he can just execute the binary. Maybe indeed less surprising for people who only know scripting languages.
For nimcache -- I am using this to not stressing my SSD too much (with /tmp mounted to ram):
cat nim.cfg nimcache:"/tmp/$projectdir"
You are talking about "beginner programmers" -- when you mean people with absolutely no prior programming experience, then we have to think about if we should recommend Nim at all for these people. I think Nim can be a good first (and only) language for these people, maybe at high school or first university course. But we know that it is not yet used there. And for self studies Nim may be still a bit hard, as we have not large numbers of very good quality documentation and large user communities in all mayor native languages. Also we don't have libraries for all possible use cases beginners may be interested in, and finally the compiler still has some minor bugs, which also is not that optimal for beginners.
Oh, and the other thing to note is that we're working on the new runtime, where strings and sequences can be non-GC. This brings both types closer in nature to primitives, as mentioned. Personally, I always initialize my strings and sequences with "" and @. I think this feels better than using a proc, because these types are builtins. So if we are considering switching to initSeq and initString, how about just "" and @?
Ill try to show that Nim 1.0 programming language standard library should not be 1:1 with the bunch of modules that currently ships with the Nim reference implementation.
A programming language is not only a syntax, but also a runtime. At minimum, a runtime should offer functions for input and output. The more batteries in the runtime, the better for the end user. When designing a runtime, especially these non-functional requirements should be considered: performance, implementability, maintainability, applicability, usability and portability. The portability of runtime library can be ensured by standardizing it, whereupon it is called the language’s standard library. A standardized library ensures that source code will work across implementations and later versions. For example, standard library 1.0 source code written for compiler A implemented by company B for operating system C targeting machine D will work without refactoring with standard library 1.6 for compiler X implemented by community Y for virtual machine Z.
- stdlib: The forthcoming Nim 1.0 programming language standard library
- cnimc:The Nim compiler reference implementation targeting C
- nimcc: The application containing cnimc and jsnimc that can be installed from here
- nimcc library: The collection of modules that ships with nimcc, as listed here
stdlib should be a non-empty proper subset of nimcc library
Proof, in 3 parts
Part 1: stdlib should be non-empty (Proof by contradiction)
If stdlib is empty, it would essentially mean that stdlib would equal system.nim. To prove that stdlib should be non-empty, it is enough to show one module that should be included in stdlib. We use macros module for this. It is stated at Nim official website, Wikipedia, and Nim in Action book that metaprogramming (hygienic term rewriting macros) is one of Nim’s core features. A standard library without macros module would therefore define a language that is not Nim.
Part 2: stdlib should be proper subset of nimcc library (Proof by reductio ad absurdum)
Part 3: stdlib should not be a superset of nimcc library (Proof by contraction)
The label 1.0 signals that the language is production-ready. If stdlib would contain a module that is not shipped with nimcc, it would mean that no reference implementation for Nim exists, and therefore the language specification could not claim 1.0 status.
By elementary logic, the conjunction of parts 1-3 proves the theorem. QED.
If Nim standards committee indeed decides that stdlib will not be 1:1 to nimcc library, the set of modules shipped with nimcc must be renamed to something else.
Conventionally standard library is part of the language spec. If you look at the C Reference Manual, you'll see that roughly half of the spec is devoted to specifying the stdlib. It would remove a lot of confusion if the set of .magic modules would be named as the standard library and the "standard library" something else.
Also I think that language conformance test suite should not test any modules that are not part of the language spec. Also, Rosetta Code examples should be solved (as much as possible) with the tools provided by language spec, not with help of non-standard modules like strutils or sequtils.