Reduce String/ByteString/PosixString variants

[hasufell]

We currently have three variants of many modules. I think we should reduce these.

My idea is:

1. String is questionable overall, maybe drop it completely in unix-3.x.x.x
2. merge ByteString and PosixString... use PosixString for filepaths and short data (e.g. GroupEntry/UserEntry maybe) and use ByteString for file contents, lazy IO and other things where we don't know anything about size limits. RawFilePath should be dropped... it's not right.

So, ideally... there would be only one API. String will probably have to live much longer, but it could be debated to move it to a compat package some time in the future.

@hs-viktor @Bodigrim

[Bodigrim]

I do not expect another major version bump after unix-2.8 within a year or two. I'd just wait and see how things unfold wrt string zoo in Haskell and return to this discussion later.

[NicolasT]

Couldn't Backpack help here?

[hasufell]

Couldn't Backpack help here?

I think no one uses that.

[NicolasT]

Couldn't Backpack help here?

I think no one uses that.

Which is a bummer, because it's exactly the kind of functionality (ML-style modules and functors) that would reduce duplication 😄

It looks like Stack and some other non-Cabal build tools don't support it though, hence I guess it's ruled out for a library like unix. Which is a bummer. I may toy with a PoC, just to get familiar with Backpack.

[hasufell]

String discussions seem to be currently quite popular, so we could try to source community opinions.

[phadej]

String is questionable overall, maybe drop it completely in unix-3.x.x.x

I guess that would cascade to e.g. directory? Or will it still have String/FilePath API?

[hasufell]

String is questionable overall, maybe drop it completely in unix-3.x.x.x

I guess that would cascade to e.g. directory? Or will it still have String/FilePath API?

directory already uses OsPath and the whole String API is actually a wrapper layer over the internal OsPath API. So I don't think it really uses filepath/string based unix API anymore.

• https://github.com/haskell/directory/blob/master/System/Directory/Internal/Common.hs
• https://github.com/haskell/directory/blob/master/System/Directory/Internal/Posix.hsc

[phadej]

@hasufell then I don't think many will notice if String interface is dropped. Having a little but not so gentle push to migrate from String interface would be for the good.

[hasufell]

I do not expect another major version bump after unix-2.8 within a year or two. I'd just wait and see how things unfold wrt string zoo in Haskell and return to this discussion later.

How time flies...

I wonder if we can start a deprecation process. Any opinions @Bodigrim @hs-viktor ?

[Bodigrim]

I’m fine to deprecate String-based interface in the next minor release.

[joeyh]

OsPath is ShortByteString, unix uses ByteString. As a user of both directory and unix, if I chose to use OsPath I will then need to convert it whenever I use unix. And there is not currently any easy OsPath -> ByteString function is there? But there is decodeFS to get from OsPath to String. So deprecating String in unix will complicate anything that needs to use both.

I don't know if there is any possibility unix will be able to depend on os-string, in order to support OsPath itself. If not, unix could alternatively support ShortByteString. I realize either would mean increasing the number of variants in the short term!

[hasufell]

As a user of both directory and unix, if I chose to use OsPath I will then need to convert it whenever I use unix.

Can you be more specific?

OsString is simplified as follows:

newtype WindowsString = WindowsString ShortByteString

newtype PosixString = PosixString ShortByteString

newtype OsString = OsString
#if defined(mingw32_HOST_OS)
  WindowsString
#else
  PosixString
#endif

So you can construct/pattern match on OsString using the internals.

And there is not currently any easy OsPath -> ByteString function is there?

Why would you need that?