Re: expose strlen from Foreign.C.String

I agree with Andrew, let's just export the lifted ffi call

This suits my needs, but, regardless of my needs, seems like a perfectly
sensible addition to Foreign.C.String

Concrete addition:

foreign import unsafe "strlen"
  cstringLength :: CString -> IO Int


On Fri, Jan 22, 2021, 17:09 Viktor Dukhovni <[email protected]> wrote:

> On Fri, Jan 22, 2021 at 04:56:33PM -0500, Andrew Martin wrote:
>
> > This will eventually be used to great effect in bytestring. See
> > https://github.com/haskell/bytestring/pull/191.
>
> Yes, you might recall that I'm well aware of that (already merged) PR,
> indeed that's how I happened to recall that cstringLength# is present
> in 9.0.
>
> > To get back to the original question, I think that any user-facing
> > cstringLength function should probably be:
> >
> >     cstringLength :: CString -> IO Int
> >
> > We need a separate FFI call that returns its result in IO to
> > accomplish this. But this just be done in base rather than ghc-prim.
> > There are no interesting rewrite rules that exist for such a function.
>
> So I guess your suggestion in response to @chessai's original post:
>
> >> On Wed, Jan 20, 2021 at 09:54:30AM -0800, chessai wrote:
> >>
> >> I've wanted the following before:
> >>
> >> foreign import ccall unsafe "strlen"
> >>   cstringLength# :: Addr# -> Int#
> >>
> >> cstringLength :: CString -> Int
> >> cstringLength (Ptr s) = I# (cstringLength# s)
> >>
> >> A natural place for this seems to be Foreign.C.String.
>
> would be to instead directly implement the lifted FFI variant:
>
>     foreign import ccall unsafe "strlen"
>       cstringLength :: CString -> IO Int
>
> which probably would not need a wrapper and can be exported directly.
>
>     module Main (main) where
>     import Control.Monad ( (>=>) )
>     import Foreign.C.String (CString, withCString)
>
>     foreign import ccall unsafe "strlen"
>       cstringLength :: CString -> IO Int
>
>     main :: IO ()
>     main = withCString "Hello, World!" $ cstringLength >=> print
>
> The cost of this safety net is that it results in more sequencing than
> is strictly necessary.  It is enough for the enclosing IO action to not
> embed the length in its result in some not yet fully evaluated thunk.
>
> I guess @chessai can let us know whether the more strictly sequenced
> variant meets his needs.
>
> --
>     Viktor.
> _______________________________________________
> Libraries mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

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