Jacqueline Firth

I'm not sure that counts as context-sensitive. Whether or not a `define` behaves like `let*` or `letrec` would depend purely on the shape of the `define` itself, not on the...

@hashimmm Do you know if it works on racket BC? I don't see any reason it would be different between the two, but it seems worth checking.

@sorawee I think we should fix that by making lists _not_ implement the generic `set` or `dict` interfaces. They don't really live up to their contracts anyway - the lists...

Related work: the javascript package [`cacache`](https://www.npmjs.com/package/cacache) on npm has multiple [localized APIs](https://www.npmjs.com/package/cacache#localized-api), with the documentation _and_ the library's exported identifiers available in both English and Spanish. I would be very...

What if we just got rid of `syntax-case` altogether?

Strongly agreed. I've been using this pattern in all of the [Rebellion](https://docs.racket-lang.org/rebellion/) APIs and it makes both documentation signatures and contracts significantly more readable. A best practice I've settled on...

Is there a way to solve the problem of wrapping functions with default arguments without introducing runtime overhead? Personally I think this is more of an API design problem than...

I think `(present-value (dict-ref-option dict key))` and `(option-get (dict-ref-option dict key) default)` aren't that much different from `(dict-ref dict key)` and `(dict-ref dict key default)`, and they get around the...

Would an approach like `printf` that's based on format strings work instead? ```racket (printf "Result= ~v, ~v, ~v\n" x y z) ```

What sort of conflicts are you imagining? I don't see the risk in making `lambda`, `let`, and `define` treat `_` specially. They would have to anyway if we wanted pervasive...