Simon Schlee wrote on 9/1/19 3:28 PM:

    Try not to make identifiers be simple generic terms, like `watch`

I strongly disagree with this statement.

I think what you say is valid, and I agree in some situations.

However, we're talking about reusable third-party packages, which are used pretty much the same as much of the "standard library" of Racket.

When I look at the Racket Reference, the standard library tends to use descriptive names, like `file-or-directory-permissions` rather than `permissions`.

A third-party package analog might be `watch-file-or-directory` (or whatever the rough purpose is) rather than `watch`.

The way racket does imports is one of the things I highly value because you can use modules to aggregate identifiers from different modules/packages, resolve name conflicts by renaming / or not exporting the 2 identifiers that clash. This creates a lot of freedom to create specific sets of functionality exported by one simple module. This way I can create my custom set of things which are most needed in the particular codebase. Instead of having to write 40 lines of requires like you have to in other languages.

True, that kind of module coupling often happens, and a module to aggregate a class of exports used by a codebase can be very convenient.

That aggregating module might also, as you said, be an opportunity to fix the problems created by having all those modules export terse generic names rather than more descriptive ones.

BTW, one drawback to the exports-aggregating module for a codebase comes when any of the aggregated modules changes (or the exports change, depending on how simple the compiler's sense of dependencies and changes).  In a large system, for an aggregating module used widely, this can cause needing to recompile much of the codebase (which can be costly, in the size of system in which I think one would consider making an aggregating module like that).  Imagine the perhaps not-unusual situation of changing a module actually only used by 10% or 1% of the modules that import the aggregating module.  Coincidentally, the largest Racket system I worked on had a couple such aggregating modules, which initially made sense, until they were covering way too much stuff that got changed way too frequently, and it made the code base way more cumbersome to work with than just having the appropriate `require`s would be. (Auto-updating the `require`s would've been nice, though.)  One of them actually made a lot of sense initially -- it was a logical whole that was unlikely to change -- until that thing got more things added to it, and until we needed to actively work on that thing while testing it integrated with the system (unit tests aren't always sufficient, or aren't always the most expedient).

Finding things in the documentation is a whole other technical issue.

I agree that could be improved.  One bit of obvious low-hanging fruit (with IDE integration) is having the context of your current #lang and requires as factors in search hit rankings.  (I'm not criticizing the current documentation search; it works surprisingly well for offline search, and with not that much resources, and was very clever in how it was implemented.  I think it might've been by Eli Barzilay.)

In the interim, a boost comes from descriptive names (which also happens to be idiomatic Racket, and idiomatic Racket).  That boost might be worse-is-better, but it works.

Also, I don't think Web searches, such as of forum posts/messages, articles, code repos, etc., are sensitive to ad hoc import renaming.  So you might get better global search hits for "racket file-or-directory-permissions" than "racket file permissions".


Racket2 aside, since you might be looking for terseness in some regard... One of the higher-level (but not top-level) requirements for Racket2 might concern terseness.  Not just in naming, but in other things as well (e.g., does a mutating or definition form also produce a value, so that it can be embedded in, say, the condition of a loop; and perhaps somehow easing the burden of expressing big imports sets).  Base Scheme is one of the less-terse of languages I know, and that took a little getting used to, though eventually I decided it resulted in a good balance of overall readability (and I could layer over the base when that helped).  But maybe Racket2 decides to go more terse in the base, which might be reasonable.  In any case, that's a bit of language design space choices, which, in the context of Racket, I think should be traced back to top-level requirements (e.g., why is the language being made at all, for whom, for what purposes, and why that), and influence much of the other requirements below it.  (I'm saying "requirements" lately because it's a software engineering framework that should help us be clear about things we haven't yet been, though I initially thought we didn't need the formality.)

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 view this discussion on the web visit

Reply via email to