Hi Marc,
I meant except for nondeterministic behavior caused by macros, so your example below is excluded from the definition.
The compiler uses gensym a lot, this would be a primary cause of nondeterminism wouldn't it, so for instance if thread-safe determinism would be desired, the Gambit user would need to implement a thread-local gensym, correct?
(This would exclude thread preemption interrupts and GC as sources of nondeterminism - thread preemption and GC would only effect |compile-file| in the way that it could affect the order of gensym calls, right?)
Oh hashtables as a source of |compile-file| nondeterminism, interesting - what does |compile-file| use hashtables for?
Thanks!!
Adam
You’ll have to define what it means for the compiler to be deterministic. Do you expect the compilation of the following program to yield the same executable every time it is compiled?
(define-macro (stamp)
(read-line (open-tcp-client "time-a.timefreq.bldrdoc.gov:37")))
(pp (string-append "hello! " (stamp)))
Macros open a big can of worms…
If you avoid macros the compiler is probably mostly deterministic… but I do not have a proof handy! Hash tables, GC, thread preemption interrupts, etc can introduce nondeterminism that may be observable in some situations.
Marc
Hi Marc,
Gambit's compiler is deterministic right?
(As in Scheme to GVM, GVM to C or binary. Underlying C compiler's determinism is a separate matter altogether.)
A consideration could be that compilation output is a function of |gensym| and therefore its counter must be managed for deterministic compilation.
Another consideration that if running more instances of the compiler in one Gambit process concurrently, the |gensym| calls could have arbitrary order and therefore determinism break.
Adam
