Is there a way to define a macro that can be dropped into a match statement? I’m working with very deeply-nested JSON and I want to be able to define something like this:

(define-simple-macro (Range Start:id End:id)
  (hash-table ['start (? number? Start)]
              ['end (? number? End)]))

So that I can do this:

(match some-hash-table
  [(Range my-start my-end)
   (+ my-start my-end)])

But when I try it, match throws a syntax error, complaining about the expr (Range my-start my-end). Is there a reason this isn’t allowed?

@cfinegan define-match-expander

http://docs.racket-lang.org/reference/match.html?q=define-match-expander#%28form._%28%28lib._racket%2Fmatch..rkt%29._define-match-expander%29%29

thank you this is perfect!

Sorry if this has been discussed before: why does (* 0 +inf.0) results in 0 rather then NaN?

@sorawee For no reason other than multiplying anything by exact 0 is exact 0. (* 0.0 +inf.0) is +nan.0.

(add1 @lexi-lambda)

I’m in the process of building a library that’s shaping up to have ~10 source files. Is there a standardized way of arranging tests for them in the Racket world? I’m thinking I could test them all in a test.rkt, or put a related test module into each source file, or put separate test files into a private/tests directory.

Additional test module inside each file seems the cleanest in my mind

Although that would change the runtime deps to include rackunit, wouldn’t it?

@royall there’s generally three ways to do this, depending on how heavyweight the tests are

First, test submodules. That works for most simple tests.

Second, you may include a tests directory in your package. That packages deps are automatically ignored for consideration in “runtime-deps”, so you may write your tests as normal Racket files (you don’t need to put all the code in submodules).

Third, make a wholly separate foo-test package for your foo package. This is typically done when the libraries used for testing are too expensive to include even as only build-deps, either because you’re using multiple heavyweight packages only for testing or your package is used by a lot of other packages so minimizing its dependencies is really important

Thanks! Test submodule sounds good for this project

Especially after reading this: >The test submodule imports rackunit for its check form, but that import does not create a dependency on rackunit (which is a substantial library) for modules that import “fish2.rkt”; the dependency is only for the test submodule.

Right, submodule dependencies are different from the dependencies of their parent modules