> It might look useful for simple cases
Which is what people do the majority of the time, especially when getting
acquainted with a new language. Simple things should be simple and clean.
> but what happens when you want to import an operator? Or if you want to
> import a hash procedure that
It might look useful for simple cases, but what happens when you want to import
an operator? Or if you want to import a hash procedure that the `tables` module
should have access to? Using a macro like that will just be an uphill battle
and shouldn't be encouraged. The "import everything into
This is a great macro you made **@Libman**:
macro load*(modulesSeq: varargs[untyped]): untyped =
result = newStmtList()
for module in modulesSeq:
result.add parseStmt("from " & $module & " import nil")
# Usage example
load os, math
That would be consistent and logical. But (IMHO) pragmas are ugly...
Could the {.pure.} pragma be made to work with imports the same as it works
with enums?
Example:
import math {.pure.}
echo cos(1.0) # Error
echo math.cos(1.0) # OK
(My previous post was posted before mapi's post became visible due to new
account moderation.)
> Only I used `require` for its name.
The three related keywords (`import`, `include`, and this proposed new one)
should be easy to remember which is which.
* `include` reminds people of C
> Writing `from blah import nil` for every import is ugly
Probably less idiomatic/encouraged way should not be absolutely the same easy,
as more idiomatic. So two extra words for the whole imports list should be OK,
it could be like this: `from xxx, yyy import nil`.
Looks like my `load` macro example has become `require` [on
Reddit](https://www.reddit.com/r/nim/comments/6p0q72/help_with_a_macro/) (which
I am now boycotting, along with the rest of social media, due to the
_still_-unexplained [shadow censorship
@Libman Oh man, I've spend this whole day learning about how macros in Nim work
only to recreate the exact same macro you've listed. Only I used `require` for
its name.
Too bad it doesn't read args from the next line like usual sections can.
> Yeah, unused imports still increase binary size despite deadCodeElim
> (--d:release --opt:size). In a perfect world that would not be the case...
How so? That needs to be fixed then.
> if the condition is never met importing xyz is wasteful
Yeah, unused imports still increase binary size despite deadCodeElim
(`--d:release` `--opt:size`). In a perfect world that would not be the case...
* * *
> you can use `from math import nil`
Yup. But I
well importing in a local block/function has nothing to do with runtime
importing. Just see scala import.
[https://en.wikibooks.org/wiki/Scala/Import](https://en.wikibooks.org/wiki/Scala/Import)
and yes for your case use a when clause. The content of a when brach is at top
level it does not
As @stisa mentioned above, runtime imports are not really possible in Nim
because Nim is not an interpreted language. Runtime imports are possible in a
language like Python because the CPython VM can stop execution in a scope to
import a module. Nim, however, pulls in modules at compile time.
For 1, if the condition is available at compile time (generally this means
`abc` and `def` are `const`) you can use a `when` block to import the module,
eg:
when cond:
import foo # this is only imported if `cond` is true and evaluable at
compile time
if cond:
14 matches
Mail list logo
