@Araq

> What are the use cases? What is it you need to do at compile-time that's 
> otherwise impossible?

I would simply like to use the entire std lib at compile time. For example, 
sometimes it's annoying to not be able to use the regex module (although 
nitely's pure nim library can be used as an alternative). Or to be able to read 
a large file at compile time (several GB), since staticRead has to read in the 
entire file at once.

> In the past I've seen an over-use of CTFE causing bugs and problems.

That may be true, but it should be up to the programmer if they want to 
over-use it. But I understand where you're coming from. Debugging issues 
related to this would be hard and probably a huge time sink.

> The primary motivation for CTFE in Nim is Nim's macro system, the full VM was 
> designed for macro evaluation. For the other use cases we could come up with 
> a better staticExec mechanism so that we generate Nim source code as an 
> intermediate step. This code can then be checked-in and is not machine 
> specific. A mechanism like that could also make #defines importable as const, 
> an often requested feature.

I love this idea too. However, I still think CTFE is valuable for the sake of 
being able to use the entire std lib. It also allows someone to use C libs at 
compile time with other targets, specifically JS.

@PMunch I agree with you completely. Sometimes you have to "roll your own" at 
compile time even if there's already a C library that does what you need.

@cumulonimbus

> But invading the compiler's memory address space is a recipe for disaster. At 
> first it will work, but down the line people will complain that the nim 
> compiler is buggy and unstable, but it will later turn out that the crash is 
> caused because of a memory corruption caused by importing a library 3-layers 
> deep which uses the compile time FFI.

That may be true. A compiler flag to have it turned on with some docs saying 
"this feature is very powerful and may cause issues if used too extensively". 
You can easily cause confusing memory corruption in "normal" Nim now by doing 
weird emit statements or playing with pointers. Just because it's dangerous 
doesn't mean it shouldn't be allowed. It should be up to the programmer to use 
the feature responsibly.

Reply via email to