I propose the following proc renames (and a few additions):
- Rename macros.name -> procName
- Benefits: Make it clear that it's for procs only. Disambiguate it from typetraits.name.
- Rename typetraits.name -> typeName or typeToStr or staticName.
- Benefit: Emphasise that it's the static type name.
- Add a new proc typetraits.genericType that returns "seq" or "MyGenericType" rather than "seq[int]" or "MyGenericType[int, float]".
- Benefit: I've needed it in the past, so I suspect other people might too.
- Add a new proc typetraits.genericTypeFmtStr that returns "seq[$1]" or "MyGenericType[$1, $2]" rather than "seq[int]" or "MyGenericType[int, float]".
- Benefit: I've needed it in the past, so I suspect other people might too.
- Rename getType(n: NimNode): NimNode -> getExprType or getResolvedType or getTypeNode or something similar
- Benefit: Emphasise that it's not returning either a typedesc or a string.
- Rename getType[](n: typedesc): NimNode -> getTypeNode or something similar
- Benefit: Emphasise that it's not returning either a typedesc or a string.
I really like the recently-introduced meta types untyped & typed -- they're much clearer in their roles than expr & stmt were.
What are the future plans for expr & stmt? In the release announcement for Nim 0.11.0, it was stated "system.untyped and system.typed have been introduced as aliases for expr and stmt. The new names capture the semantics much better and most likely expr and stmt will be deprecated in favor of the new names."
Nim makes an explicit distinction between statements & expressions: "Nim uses the common statement/expression paradigm: Statements do not produce a value in contrast to expressions. However, some expressions are statements."
Hence, rather than removing expr & stmt entirely, would it be possible to retain expr & stmt as return-types for templates & macros, such that expr is type indicating an expression that produces a value (that might be written as expr[T]) while stmt is a convenient type for a NimNodeKind of nnkStmtList?
I propose the following module renames, to improve descriptiveness of the type information module names:
- Rename module typeinfo (runtime type info) -> rtti or runtimetypeinfo or dynamictypeinfo
- Because "typeinfo" is not clear whether it's runtime or compile-time, whereas RTTI is a generally-understood acronym.
- Rename module typetraits (compile-time type info) -> ctti, stti or statictypeinfo
- To mirror rtti or runtimetypeinfo.
I understand that the module names typeinfo & typetraits are taken from the C++ Standard Library, but they're really not very clear names regardless of their pedigree. I also understand that Nim's macro & template system greatly reduces the need for a compile-time type info module (which is why Nim's typetraits module is so minimal), but there's no reason to hide what's there behind a cryptic name.
I think that "macro time" & "compile time" are too blurred-together conceptually (at least in the Nim language model that is presented in the Manual & the system module docs). And that's not even getting started on static blocks or the evaluation of const statements and generic types.
And in terms of names: Having compileTime procs is a good clear name. But then static is used for both static blocks & static[T] (and implicitly for "static types").
For example, I think it would be an improvement if the term "static" was used only for static types, with static blocks renamed to compileTime blocks (or something similar) and static[T] renamed to const[T]... or some distinction like this.
Thoughts? Feedback? Polite explanations of why it wouldn't work?
Hence, rather than removing expr & stmt entirely, would it be possible to retain expr & stmt as return-types for templates & macros, such that expr is type indicating an expression that produces a value (that might be written as expr[T]) while stmt is a convenient type for a NimNodeKind of nnkStmtList?
Sure, but then I'd prefer value vs void for this distinction. Having both void and stmt is weird. And value is very close to auto...
More generally, because Nim's macro & template system is so powerful, I think it would be worth drawing a more detailed distinction than the traditional "compile-time" vs "runtime".
That's surely a good idea, but more helpful at this stage would be to document in the manual how it's actually done in the compiler. :-) The terms I prefer are syntax time and sem(antics) time.
Further notes:
Hi @Araq,
Sure, but then I'd prefer value vs void for this distinction. Having both void and stmt is weird. And value is very close to auto...
Surely void and stmt are very different? I thought that void means that your proc returns nothing, whereas stmt means that your macro returns a statement list?
I can see that expr is closer to auto, but I think there's a benefit to keeping expr distinct from auto, as a type (the sibling of stmt) that can only be returned by templates & macros.
That's surely a good idea, but more helpful at this stage would be to document in the manual how it's actually done in the compiler.
Without volunteering myself to do it, I would be very glad to read more information in the manual about the ordering of the phases in the compiler.
The typetraits module should just be removed. macros.getType is the future.
I always interpreted the typetraits module as relating to static types & generic types (and the generics compilation phase), which I understood as distinct from the macro types & compilation phase (which I thought of as more of a compile-time VM).
Is this an incorrect understanding on my part? Has there been a change over time to integrate generics & macros more closely?
How/when did the typetraits module first appear?