<HTML><BODY>We already have bound-id-table-iterate-first, module-identifier-mapping-for-each and so on. They are too long. And completion in DrRacket doesn't help a lot, because it gives all in documentation, not all in require (why?). Idiomatic names good when there are only one implementation of every thing. But take, for example, FFI to .Net, Gtk ,Qt: we will have gtk-list, gtk-list-length, gtk-list-first, qt-list, dotnet-list, .... Then for QuickTime will have QT-... to distinct QT-video from qt-video. And if we have two implementation of GTK FFI (one through g-object-introspection and one native), then we will have to make gtk-gi-list and gtk-native-list and so on. > With the level of third-party reuse that I and my consulting clients have been doing over the last 10 years with Racket, I found that we only rarely use "prefix-in" Only because Racket is still young. For Common Lisp name clash is very common. And even in Racket: `->' is both in ffi and contract `array' in math and ffi `extract-desired-headers' in nntp and pop3 `set' in racket/control and racket/set So may be better to propose prefix-in as the main usage mode. When package is not designed for prefix-in one has double prefix: For example, set is in racket/control and racket/set. But with prefix-in one has set:set-eqv?, set:weak-set and even set:gen:set and set:list->set -- it is awful. In my packages I only try not to interfere with base racket bindings. And make names concise (no prefixes). Because we have prefix-in, but don't have prefix-remove. Sun, 06 Jul 2014 23:10:21 -0400 от Neil Van Dyke <neil@neilvandyke.org>: <blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"> <div id=""> <div class="js-helper js-readmsg-msg"> <style type="text/css"></style> <div> <base target="_self" href="https://e.mail.ru/"> <div id="style_14047026310000000601_BODY"> Roman Klochkov wrote at 07/06/2014 10:15 PM: > What about 3rd party modules? > > For example, should > <a href="http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss" target="_blank">http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss</a> provide > syntactic-closures-compile, syntactic-closures-execute and > syntactic-closures-scheme-syntactic-environment ? Idiomatic names might be "compile-syntactic-closures", "execute-syntactic-closures", etc. If this library became a very common thing to use, familiar to most Racket programmers, maybe someone would come up with catchier names eventually (like "call-with-current-continuation" became "call/cc"). > > Collections may be renamed. Eventually collection names will become > longer, because they have to be unique (like in > java: org.apache.commons.lang.builder.ToStringBuilder). Besides we > have modules and prefix-in. I suspect that, in practice for the foreseeable future, if we use non-generic names, we won't have many collisions. With the level of third-party reuse that I and my consulting clients have been doing over the last 10 years with Racket, I found that we only rarely use "prefix-in". This is out of over 1,000 Racket modules and over a million of lines of Racket code, written by several people of varying background and style. My recollection offhand is that, when we have used "prefix-in", it's for improving code readability when: * using the profiler (due to its use of generic names like "render", used in large modules that often dealt with more prominent/likely ``render'' concepts), * using the old SSAX/SXML PLaneT packages (due to not-entirely-idiomatic API and packaging), and * using some SRFI implementations (due to name conflicts), * doing Scheme/Racket dialect language work (to keep straight what dialect's identifiers we're talking about in a module). All other times I can think of, having sensible non-generic names and not needing the headache of "prefix-in" has seemed to be a win. Granted, I have a research interest in much more heavy fine-grain reuse, and if that's ever realized, I assume we'll see more identifier collisions and more confusing overloading of terms (e.g., the several different kinds of "date" objects I've seen in various code). I couldn't say for certain that generic names and "prefix-in" (or some other facility) wouldn't start to be practical at that time; I'd have to wait and see. Of course, the programming language technology is not the only way that these problems are solved, but can be solved in the ecology of development and reuse (e.g., as development and reuse sophistication increases, we might actually see fewer different kinds of things called "date" than we see now, since one kind might mature more, and consequently people might less often have occasion to make an alternative one). Neil V. </div> <base target="_self" href="https://e.mail.ru/"> </div> </div> </div> </blockquote> -- Roman Klochkov </BODY></HTML>