Bikeshedding the cstringLength name?

[Edward Kmett]

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 <ietf-dane at dukhovni.org>
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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210125/10afac9a/attachment.html>