Don't export n->th?

Show & Tell
1

n->th is exported from racket/contract, and consequently by racket. However, this function is not documented, and intentionally so (racket/base.rkt at e028f252da859759100f9248230bdc4e203a6684 · racket/racket · GitHub). To be more precise, it was unintentionally exported in the past, and my guess is that it was later decided that it's (somehow) too late to remove it from the export list.

This, of course, feels wrong to many people, including me. There seem to be three possibilities here:

  1. Leave it as it is
  2. Arguably, this function is useful and could be documented, but racket/contract is definitely not the place for it. Perhaps move it to racket/string instead? Perhaps need to check that inputs have correct types too (without using the contract library to avoid circular dependencies).
  3. Remove it from the export list. I don't see why doing so would cause trouble, since no one knows it exists anyway (well, this might become false after this thread is read).

What's the best option? Am I missing anything?

CCing @robby who commented that it's intentionally undocumented.

3 Likes
2

I would prefer to get rid of it, but we should do some due diligence to try to make sure that nothing breaks and preferably having in unexported for a full release cycle before it is really turned off.

3

Just so you can improve the gameplay of Rackedle, isn't it? :stuck_out_tongue_winking_eye:

1 Like
4

@Laurent.O: well, that's a part of it :wink:

@robby: thanks! Will submit a PR after 8.5 is released.

5

The hard part is figuring out if anyone's using that export, right? Is that something you're willing to help with?

6

Had to look around for it:

  (string-append
   (number->string n)
   (case (remainder n 100)
     [(11 12 13) "th"]
     [else
      (case (modulo n 10)
        [(1) "st"]
        [(2) "nd"]
        [(3) "rd"]
        [else "th"])])))

Seems pretty useful. Any reason not to keep it and add it to the documentation?