Yes, this worked for me, thank you. It also uncovered a bug in my
tests where test namespaces where leaking out of the tests, thus
affecting future tests.
Thank you again.
~Leif Andersen
On Sat, Dec 26, 2015 at 6:23 AM, Matthew Flatt wrote:
> At Fri, 25 Dec 2015 16:58:53 -0700, Leif Andersen w
At Fri, 25 Dec 2015 16:58:53 -0700, Leif Andersen wrote:
> That's what I thought initially too, but it didn't seem to make a
> difference when I used
> `expand-syntax-top-level-with-compile-time-evals`, although then I
> realized that perhaps a better function to use would be
> `eval-compile-time-p
> Well, considering my past performance you definitely don't want to to
trust me on these questions, but I'll give it a try anyway. :)
Ha, well I appreciate the attempt anyway.
> My guess is that when you comment in only this line from the last two:
> (eval (compile prog))
> then the "x" is
I agree with Robby's explanation on just the `compile` line.
When you uncomment both lines, it's the same error as as
> (module m racket/base (define x 5))
> (require 'm)
> (module m racket/base (define x 5))
define-values: assignment disallowed;
cannot re-define a constant
constant: x
Well, considering my past performance you definitely don't want to to
trust me on these questions, but I'll give it a try anyway. :)
My guess is that when you comment in only this line from the last two:
(eval (compile prog))
then the "x" is compiled into a reference to a top-level variable,
I should probably also mention that if I comment out the first eval
leaving only `(compile (eval prog))`, I get:
x: undefined;
cannot reference undefined identifier
Which leads me to think that the other error is from trying to require
the same module twice in the same namespace.
But I'm stil
6 matches
Mail list logo
