The code duplication was there only to support
constructing the name for the optimized contract;
instead we actually just built the name as we go
(the old version actually built the old contract
and then used that to get the name)
also:
- racket/contract/base now requires basic-opters.rkt
so all of the opters are registered when racket/contract/base
is loaded, not just the non-basic ones
- fix the ordering of the names of subcontracts in or/c
- make opt-contracts print a more meaningful name
* Some racketisms.
* Use explicit `in-list' etc in for loops.
* Remove some redundant requires from `net/dns'.
* Move all tests to `tests/net', including a new `tests/net/ip'. In the
future there's a plan to have things like stripped zos etc for
distribution, but we're not there yet, and the net collection is
already organized nicely so this also makes it more uniform.
* Include the dns tests in the main test file.
For instance, (normalize-arity (list 1 (arity-at-least 2))) now produces
(arity-at-least 1). The implementation and the tests for normalize-arity both
reflect this change. The randomized tests now also check that the output
represents the same arity as the input.
The lexer mishandled cases like "#x1E+2", because "E" is
not an exponent marker for hexadecimal --- and it has been that
way forever, but the repair isn't all that difficult.
These result from something like
@racket[(x y)]
being treated by Scribble as multiple RktXXX items rather than one. As
a result the Markdown emitted was:
`(``x`` ``y``)`
But obviously instead we want:
`(x y)`
Kludgosity alert: Although it would probably be more-correct to
consolidate the RktXXX items at the Scribble structure level, I don't
easily see how. `@racket` is baking in the concept of Racket
lexing (classifying text as various kinds of Racket elements). This is
handy when the render will be HTML or Latek, and is benignly N/A when
it will be plain text. But it's a bit square-peg/round-hole when the
render will be Markdown. Rather than attempt to "un-lex" the Scribble
structures (I'm having trouble seeing how), I'm handling it
"after-the-fact" -- adjusting the generated Markdown text.
If anyone thinks the preceding is an elaborate rationalization for an
ugly kludge, I wouldn't argue, but I would need some help
understanding the preferable way to go about it.
Unlike plain `racketblock`, `examples` and `interaction` are
"nested". As a result we emitted bad Markdown like:
```racket
Examples:
```racket
some-code
```
```
Markdown code blocks can't nest, so this needs to be:
```racket
Examples:
some-code
```
Also: Updated the unit test with examples of `examples` and
`interaction`.
