I just noticed a handful of spelling errors, in a package that isn't all that obscure. Enums from a C interface - data AlarmingNews = -- ALARM_STUFF_WENT_WRONG AlarmStufWentWrong | ... (oops, should have been Stuff, not Stuf.) Who can blame the guy, after all, because this renaming work is not only kind of a mind-numbing and trivial job, it's quite gratuitous. Of the people who are apt to be interested, a sizeable percentage already will be familiar with ALARM_STUFF_WENT_WRONG, and as the "nice" Haskell spelling offers no practical advantage at all, it's purely a waste of their time to translate from one to the other. Is screenflicker_frequency() going to be screenFlickerFrequency, or screenflickerFrequency? gah! I know it's enshrined in many years of convention by now, but if anyone might ever consider the matter again, my vote would be, when adopting foreign interfaces essentially unchanged, that the spellings also be preserved to whatever extent practicable. thanks! Donn Cave
On 7 Feb 2011, at 03:10, Donn Cave wrote:
I just noticed a handful of spelling errors, in a package that isn't all that obscure. Enums from a C interface -
data AlarmingNews = -- ALARM_STUFF_WENT_WRONG AlarmStufWentWrong | ...
FWIW, if you generate these bindings with a tool (e.g. hsc2hs, c2hs), then there are standard machine-generated translations, which follow simple rules (so are easy to guess) and being mechanical, are always spelled as expected. For example aLARM_STUFF_WENT_WRONG for a constant Haskell Int value corresponding to the C enum or CPP constant. Regards, Malcolm
On Sun, Feb 6, 2011 at 10:10 PM, Donn Cave
Of the people who are apt to be interested, a sizeable percentage already will be familiar with ALARM_STUFF_WENT_WRONG, and as the "nice" Haskell spelling offers no practical advantage at all, it's purely a waste of their time to translate from one to the other. Is screenflicker_frequency() going to be screenFlickerFrequency, or screenflickerFrequency? gah!
I don't think it's this simple. It is disheartening to innocently download a library from Hackage to find that it only supports a very non-Haskelly API. Why am I being punished by the history of a library? To support both kinds of users, we have designs like that used in the OpenGL library: a Foo-Raw library, with a friendlier API layered on top, perhaps in a separate package. If the "friendly" API turns out to be no friend of yours, you are free to turn to the raw wrappers. Perhaps we should aim for a more systematic application of this design pattern? I know that I appreciate a more idiomatic Haskell API when it is available, and certainly do not want library authors discouraged from providing such a service solely due to the provenance of the functionality. On the other hand, when I am porting, say, C coded against a particular API to Haskell, being able to use a more symmetric API is beneficial. One can keep both APIs in the same package until a legitimate desire to split them arises (e.g. to provide alternate high-level APIs). Anthony
Quoth Anthony Cowley
To support both kinds of users, we have designs like that used in the OpenGL library: a Foo-Raw library, with a friendlier API layered on top, perhaps in a separate package. If the "friendly" API turns out to be no friend of yours, you are free to turn to the raw wrappers.
Perhaps we should aim for a more systematic application of this design pattern? I know that I appreciate a more idiomatic Haskell API when it is available, and certainly do not want library authors discouraged from providing such a service solely due to the provenance of the functionality. On the other hand, when I am porting, say, C coded against a particular API to Haskell, being able to use a more symmetric API is beneficial.
I don't know the OpenGL example, but I gather you're talking about an API that's different in a practical way, not just a thin layer with the names spelled differently. In that case, assuming that it really is more Haskell-functional-etc, vive la difference! No one would argue with this, I think. I just think that's how far you should have gotten, before you need to think about new Haskell-style names. For examples where someone apparently felt that new names for everything was the first order of business, you could look just about anywhere in System.Posix. System.Posix.Terminal - at least the documentation helpfully reveals the actual POSIX 1003.1 function names, but try for example to figure out what has become of the the fairly commonly used "ICANON" flag, without looking at the source. If you're hoping that in the course of time a significantly functionally designed API will come along for any of these things, note that names it might have used are already taken. Donn Cave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/7/11 12:36 , Donn Cave wrote:
I don't know the OpenGL example, but I gather you're talking about an API that's different in a practical way, not just a thin layer with the names spelled differently. In that case, assuming that it really is more Haskell-functional-etc, vive la difference! No one would argue with this, I think.
Usually the low level one is merely a thin layer, whereas the high level one is more than just Haskell conventions but a proper Haskell-style API, using e.g. monads instead of opaque state blobs.
helpfully reveals the actual POSIX 1003.1 function names, but try for example to figure out what has become of the the fairly commonly used "ICANON" flag, without looking at the source. If you're hoping that in the course of time a significantly functionally designed API will come along for any of these things, note that names it might have used are already taken.
+1. The stuff that's a thin wrapper, such as System.Posix.*, should keep names as close to the API it's mirroring as possible; if you want to rename them, do it in the context of an actual Haskell API. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1QiYsACgkQIn7hlCsL25UZ4gCgrS2vGDNqk0QPyPB9+ZVCCYHi oBsAnA5XJyHSozeEny+xlnNcL+K5ZfAy =AfVP -----END PGP SIGNATURE-----
participants (4)
-
Anthony Cowley -
Brandon S Allbery KF8NH -
Donn Cave -
Malcolm Wallace