Bikeshedding the cstringLength name?

[Viktor Dukhovni]

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Edward Kmett-2]

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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

[Viktor Dukhovni]

On Mon, Jan 25, 2021 at 08:09:01PM -0800, Edward Kmett wrote:

> [...Sound argument for consistency of style...]
>
> Names matching primitives modulo a hash is pretty universal as well.

Just on this one point, the reason I contemplated something different
than `cstringLength` and was led to `bytestring` as a possible model,
was because the primop is differs subtly from the new lifted function
by being "pure" (and is then only safe for compiled-in constants).

Since the proposed lifted variant changes not only the levity but also
the purity, I thought it worth asking whether that could be a source of
confusion, with some users accidentally misusing the primop, expecting
only a difference in levity.  But likely I let my imagination run wild.

The proposed name is fine.

--
    Viktor.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries