Re: [racket-dev] generic API names considered harmful
What about 3rd party modules? For example, should http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss provide syntactic-closures-compile, syntactic-closures-execute and syntactic-closures-scheme-syntactic-environment ? 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. Even in Common Lisp, Google propose omit prefixes in names: http://google-styleguide.googlecode.com/svn/trunk/lispguide.xml?showone=Omit_library_prefixes#Omit_library_prefixes I propose the same: every module should provide only short names without prefixes. Modules like `racket' should re-export the names with approptiate prefixes. Something-like syntax/bound-id-table.rkt (provide ref set set! remove ...) syntax/id-table.rkt (require (prefix-in bound-id-table- bound-id-table.rkt)) (provide bound-id-table-ref bound-id-table-set ...) Fri, 04 Jul 2014 19:30:44 -0400 от Neil Van Dyke n...@neilvandyke.org: For documented public API of modules that are part of core Racket, shouldn't pretty much all the identifiers be descriptive enough to be unique within the scope of core Racket? (Excepting name conflicts from SRFIs and teaching languages?) I've now noticed generic API names like make and render in core Racket modules written by, I think, 3 different very smart core Racket developers. I don't understand why we're still doing this. Was it for use with the unitssignatures (which are more trouble than they're worth, IMHO)? For code using these APIs, for readability (since any generic names in a module are relative to what that module is about, not the possibly many modules that module uses), I end up using prefix-in on modules with generic API names, which is still harder to read than natural identifiers. And even if I do the prefix-in like foo-lib:, with a colon on the end, foo-lib:make is still harder for someone reading the code to look up the identifier in Racket doc search, compared looking up a unique API identifier like make-foo or foo-make. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev -- Roman Klochkov _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] generic API names considered harmful
Roman Klochkov wrote at 07/06/2014 10:15 PM: What about 3rd party modules? For example, should http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss 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. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] generic API names considered harmful
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 n...@neilvandyke.org: Roman Klochkov wrote at 07/06/2014 10:15 PM: What about 3rd party modules? For example, should http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss 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. -- Roman Klochkov _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] generic API names considered harmful
I am one of the guilty. The dispatcher system uses 'make' everywhere and I intend people to use prefix-in: (prefix-in lift: web-server/dispatchers/dispatch-lift) (prefix-in fsmap: web-server/dispatchers/filesystem-map) (prefix-in sequencer: web-server/dispatchers/dispatch-sequencer) (prefix-in files: web-server/dispatchers/dispatch-files) (prefix-in filter: web-server/dispatchers/dispatch-filter) (prefix-in servlets: web-server/dispatchers/dispatch-servlets) (prefix-in log: web-server/dispatchers/dispatch-log)) This was originally an attempt to make it so dispatchers would be dynamically load-able, so they'd need to have a common name that the outside could expect. After implementing it and having some time with these, that didn't seem like a worthwhile idea anymore. I basically agree with you Neil. Jay On Fri, Jul 4, 2014 at 5:30 PM, Neil Van Dyke n...@neilvandyke.org wrote: For documented public API of modules that are part of core Racket, shouldn't pretty much all the identifiers be descriptive enough to be unique within the scope of core Racket? (Excepting name conflicts from SRFIs and teaching languages?) I've now noticed generic API names like make and render in core Racket modules written by, I think, 3 different very smart core Racket developers. I don't understand why we're still doing this. Was it for use with the unitssignatures (which are more trouble than they're worth, IMHO)? For code using these APIs, for readability (since any generic names in a module are relative to what that module is about, not the possibly many modules that module uses), I end up using prefix-in on modules with generic API names, which is still harder to read than natural identifiers. And even if I do the prefix-in like foo-lib:, with a colon on the end, foo-lib:make is still harder for someone reading the code to look up the identifier in Racket doc search, compared looking up a unique API identifier like make-foo or foo-make. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy http://jeapostrophe.github.io Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great. - DC 64:33 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] generic API names considered harmful
For documented public API of modules that are part of core Racket, shouldn't pretty much all the identifiers be descriptive enough to be unique within the scope of core Racket? (Excepting name conflicts from SRFIs and teaching languages?) I've now noticed generic API names like make and render in core Racket modules written by, I think, 3 different very smart core Racket developers. I don't understand why we're still doing this. Was it for use with the unitssignatures (which are more trouble than they're worth, IMHO)? For code using these APIs, for readability (since any generic names in a module are relative to what that module is about, not the possibly many modules that module uses), I end up using prefix-in on modules with generic API names, which is still harder to read than natural identifiers. And even if I do the prefix-in like foo-lib:, with a colon on the end, foo-lib:make is still harder for someone reading the code to look up the identifier in Racket doc search, compared looking up a unique API identifier like make-foo or foo-make. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
