Re: [racket-users] Unit tests for a #lang implementation

2017-09-01 Thread Konrad Hinsen
Matthew, > If you'd like the test namespace and the test-driving module to share > the instance of the module that defines `document` (so that they'll > agree on the data structure), you can use `namespace-attach-module` to > attach the test-driving module's instance to a newly created namespace.

Re: [racket-users] Unit tests for a #lang implementation

2017-08-31 Thread Matthew Flatt
At Thu, 31 Aug 2017 11:31:33 +0200, Konrad Hinsen wrote: > On 25/08/2017 17:03, Konrad Hinsen wrote: > > > That adds the missing piece - thanks a lot! I had seriously > > underestimated the complexity of module definitions in Racket. > > A followup mostly for the benefit of those who find this t

Re: [racket-users] Unit tests for a #lang implementation

2017-08-31 Thread Konrad Hinsen
On 25/08/2017 17:03, Konrad Hinsen wrote: That adds the missing piece - thanks a lot! I had seriously underestimated the complexity of module definitions in Racket. A followup mostly for the benefit of those who find this thread in the archives one day. Importing a module this way works per

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Konrad Hinsen
On 25/08/2017 16:30, Matthew Flatt wrote: At Fri, 25 Aug 2017 16:04:01 +0200, Konrad Hinsen wrote: Putting those together, and using `current-namespace` so that both `eval-syntax` and check-module-form` use the same namespace: Thanks, that works! At least to the point of not getting any error

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Matthew Flatt
At Fri, 25 Aug 2017 16:04:01 +0200, Konrad Hinsen wrote: > > Putting those together, and using `current-namespace` so that both > > `eval-syntax` and check-module-form` use the same namespace: > > Thanks, that works! > > At least to the point of not getting any error message. I can't say if a >

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Konrad Hinsen
Matthias, Matthew’s response is probably all you want in principle, but I think that your ‘unit test’ looks like another person’s ‘integration tests’. Both are useful. Wouldn’t you want to use unit tests to validate the parser independently of the macros that expand the S-expression syntax you

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Konrad Hinsen
Matthew, Putting those together, and using `current-namespace` so that both `eval-syntax` and check-module-form` use the same namespace: Thanks, that works! At least to the point of not getting any error message. I can't say if a module is actually defined. A plain (require 'anonymous-mo

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Matthias Felleisen
Konrad, Matthew’s response is probably all you want in principle, but I think that your ‘unit test’ looks like another person’s ‘integration tests’. Both are useful. Wouldn’t you want to use unit tests to validate the parser independently of the macros that expand the S-expression syntax yo

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Matthew Flatt
I forgot to explain why this fails: At Fri, 25 Aug 2017 14:59:14 +0200, Konrad Hinsen wrote: > (eval-syntax > (parameterize ([read-accept-lang #t] > [read-accept-reader #t]) > (read-syntax "test-module" > (open-input-string "#lang > scribble/base\n@section[

Re: [racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Matthew Flatt
I'd say that using `eval` or `eval-syntax` is the right idea, but: * It's better to use `make-base-namespace` instead of `module->namespace`, since `(module->namespace 'racket/base)` gives you a namespace for the inside of `racket/base` instead of a top-level namespace that has imported

[racket-users] Unit tests for a #lang implementation

2017-08-25 Thread Konrad Hinsen
Hi all, I have been trying for a while to write proper unit tests for a language implementation I am working on. By "proper" tests I mean tests that are run using raco test just like any other tests. Until now, I have a separate shell-script based testing framework that runs scripts written in