In general, for good or evil, Haskell generally decided to roll its own names for everything to do with the outside world. Like I said, good or evil, because it leads to a consistent feel to the API, unlike, say something like PHP, but does raise the bar to initial entry into the language a bit. On the other hand, it strikes me as a worst of all choices to wind up with 1-2 functions that comply with outside naming, while everything else carries on as usual, because now users are in the business of memorizing exceptions rather than writing code. Internally libraries often adopt a c_foo or other mangling convention for their own FFI'd guts, but it isn't a thing base does. I'd be more interested in one of the myriad alternative base/prelude projects picking up and running with what it looks like when the names of everything look like something out of gcc, than I would be particularly interested in bikeshedding this one name into a very "unhaskelly" form. Names matching primitives modulo a hash is pretty universal as well. -Edward On Fri, Jan 22, 2021 at 7:07 PM Viktor Dukhovni wrote:

An equivalent function of course already exists outside base:

$ hoogle 'CString -> IO CSize' Data.ByteString.Internal c_strlen :: CString -> IO CSize

unsurprisingly defined as:

foreign import ccall unsafe "string.h strlen" c_strlen :: CString -> IO CSize

Would it make sense to give the proposed new Foreign.C.Types function the same "c_strlen" name? And then at some point in the future, Data.ByteString.Internal can just re-export it?

Would using `cstringLength`, as proposed, be too confusable with the `cstringLength#` primop?

-- Viktor. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries