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/
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
