[racket-dev] consistency in names and signatures

FWIW...

* I have no strong opinion on whether it would be worthwhile, if done in 
a backward-compatible way.

* If done in a *non*-backward-compatible way, it might be a headache.  I 
know of systems in production with millions of lines of PLT/Racket code, 
and -- although PLT/Racket have been pretty good about backward 
compatibility -- it seems like every little non-backward-compatible 
change to a PLT/Racket version, my big clients feel it significantly.  I 
make a little money every time a platform change inflicts pain, since I 
have to fix it, but it's a net loss for me when goodwill for the 
platform is eroded.  (And perhaps eroded goodwill for me, who is 
implicitly endorsing the platform, and who has sometimes been asked 
directly to explain *why* such-and-such changed happened.  I would 
rather be paid to invent and build new stuff, not be responding to the 
platform breaking.)

* I am sympathetic to the idea of being more explicit about types in 
identifiers.  In nontrivial code, I do sometimes end an identifier as 
"-or-false" or "-or-f", and sometimes I have "/error" or "/exn" variants 
of procedures.  It helps me keep track of whether the value can be #f.  
I usually avoid being this explicit in identifiers in APIs, because it's 
a little ugly-looking, it has not been idiomatic Racket thus far, and it 
hasn't seemed necessary.

* If we're going to have exception-raising and #f-producing variants of 
a procedure, how about accommodating both the little language and big 
language people by having *three* variants: "/exn" and "/f" (or 
"/false") for the big language people who want to be explicit, and 
no-suffix for the littler language people who don't need or want all 
that clutter.

* Would this new world of naming conventions be a good time to replace 
the somewhat clunky-looking "->" naming convention with ">" or something 
else?  "number>string"? "number-to-string"?  "number-as-string"?  (No 
non-ASCII, unless I can get an APL keyboard for my ThinkPad.)

* Maybe we should consider otherwise simplifying some of these 
identifiers.  To use an example, "bytes->string/utf-8" is already a 
mouthful for a pretty common thing, even before we start adding suffixes 
onto it.  ("bytes->string/utf-8" might be too easy an example, since 
UTF-8 encoding would be an appropriate default for a "bytes->string" 
nowadays, and consistent with Racket's current behavior when writing a 
string to a bytes port.)

* Will there be more consistency in how "/" in an identifier should be 
read?  It seems that "X/Y" sometimes reads as "X with behavior Y", 
sometimes as "X with a Y argument", sometimes as "X or Y", and sometimes 
as something else.

Neil V.

-- 
http://www.neilvandyke.org/