avoid numeric vs textual clash in args length error #5192
Conversation
`numerals` doesn't seem to be maintained anymore, however
sellout
left a comment
There was a problem hiding this comment.
Ah, wonderful – I had made a note to look into what packages might exist for this. I was hoping for one that was also parameterized on “style” (e.g., 10 -> "ten", but 1023 -> "1,023"), but I don’t think that matters for this use case.
Just one minor suggestion.
| - recover-rtti-0.4.2@sha256:c179a303921126d8d782264e14f386c96e54a270df74be002e4c4ec3c8c7aebd,4529 | ||
| - lsp-2.2.0.0@sha256:82fbf4b69d94d8d22543be71f89986b3e90050032d671fb3de3f8253ea1e5b6f,3550 | ||
| - lsp-types-2.0.2.0@sha256:a9a51c3cea0726d91fe63fa0670935ee720f7b31bc3f3b33b2483fc538152677,29421 | ||
| - numerals-0.4.1@sha256:f138b4a0efbde3b3c6cbccb788eff683cb8a5d046f449729712fd174c5ee8a78,11430 |
There was a problem hiding this comment.
I think this probably isn’t important to anyone other than me, but I’m never sure exactly which parts of stack.yaml are picked up by haskell.nix. And the nix dev GitHub workflow doesn’t yet actually build Unison, so I’m running nix build github:unisonweb/unison/topic/numerals right now just to make sure it’s all good.
But again, I don’t think nix build should hold up the process for anyone else.
There was a problem hiding this comment.
Oh, I forgot to update this – it built fine.
There was a problem hiding this comment.
No problem. Does a passing "Nix development cache" run not indicate success here?
There was a problem hiding this comment.
No – it currently only builds the dev tools. With the LTS upgrade PR it will build everything.
Co-authored-by: Greg Pfeil <greg@technomadic.org>
Lol, I did not consider "I was expecting one thousand twenty three." But yeah I think we are safe in this case. |
Overview
Implementation notes
Just calls
Numerals.us_cardinalinstead ofshowon the number of arguments to be mentioned in the error message.Interesting/controversial decisions
numeralsdoesn't seem to be maintained anymore, but maybe that doesn't matter"zero" (the default) vs special-casing "none"
Test coverage
I attempted to add additional transcript tests to cover the under-saturated case, but couldn't due to #5190. I would create them as soon as it's possible.
Loose ends