* Remember that, although Racket is rich with various kinds of
namespaces, documentation lookup for the core Racket and add-on packages
really prefer that names are mostly unique globally. (I won't get into
readability tradeoffs, for various use cases that come up.) See thread
"http://lists.racket-lang.org/dev/archive/2014-July/014456.html";.
* For one of numerous examples of what I currently think is
usually-good-enough naming practice in reusable Racket packages, see
"http://www.neilvandyke.org/racket/roomba/";, which works the package
name into every public identifier, while remaining fairly
English-verbs-and-nouns-readable. (Even though, in the particular case
of a package of Roomba commands, we could make a good argument that they
should be shorter and more generic, since one obvious audience is young
children doing Logo-ish programming. I decided that's probably not a
good enough argument, and if we wanted that, that particular use wants
to be a "#lang". Which documentation searches and readability can and
should really handle differently.)
* Exporting both prefixed and non-prefixed identifiers from a package
pollutes the global documentation namespace.
* I think the original question might have also been asking about the
exact character forms of names from FFI, not just whether prefixed. One
convenient accident of naming convention differences between C and
Racket (e.g., underscores), when doing FFI, is that we can usually use
the C names in Racket, internally, for procedures with the most bare FFI
wrappers. That leaves the idiomatic Racket names for the exposed
interface, which might also layer small safeties and other features. And
not exporting the non-Racket-idiomatic C names from Racket packages
avoids messing up the readability of all code that uses the packages.
* (One argument *against* using Racket idiomatic names for a big API,
such as OpenGL, is that sometimes you might really want to make the
names look like the C ones, such as for people copying large masses of
example code. I'm not going to try to tackle that discussion at this
time, but will just note that transliterating some small OpenGL code
samples a long time ago was not a big deal
"http://www.neilvandyke.org/opengl-plt/";.)
* I can't resist the opportunity to reiterate one naming convention
plea: Don't use uppercase identifiers for "constants" in Racket. It was
that way in K&R C because people used the really linguistically nasty
macro preprocessor for constants (among other purposes). Then someone
started using the same thing for some better form of constants in ANSI C
and C++, making the terrible mistake of thinking that names of constants
should be uppercase in C/C++ code. (Then Java picked it up, as one of
its many attempts to appeal to the small pool of technical and embedded
systems programmers, which was funny, because all those C accidents of
implementation convenience from the 1970s were then forced on the
less-technical MIS-type programmers who overwhelmingly took over Java,
and who never had any need for things to look like cryptic C.) The
uppercase is hard to type, visually misleading regarding importance, and
a very poor use of a visually powerful mechanism. I think that the best
use of upper-case names in Racket is for pattern variables in syntax
transformers, to stand out amongst fragments of code. Using uppercase
for constants compromises that.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
