AFPP is implemented

[hasufell]

• hackage: https://hackage.haskell.org/package/filepath-1.4.100.0/docs/System-OsPath.html
• blog: https://hasufell.github.io/posts/2022-06-29-fixing-haskell-filepaths.html

[xtendo-org]

Good. Thanks for letting me know. I guess this is the beginning of a long journey to implement everything, like callProcess or getDirectoryFiles, on the new OsPath type.

This means, for Unix, having to re-implement stuff on ShortByteString instead of ByteString. I don't know how much work that will be.

[hasufell]

This means, for Unix, having to re-implement stuff on ShortByteString instead of ByteString. I don't know how much work that will be.

That is already done:

• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-PosixPath-FilePath.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-IO-PosixString.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-Files-PosixString.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-Env-PosixString.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-Process-PosixString.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-Temp-PosixString.html
• https://hackage.haskell.org/package/unix-2.8.1.1/docs/System-Posix-Terminal-PosixString.html

[xtendo-org]

@hasufell No, it's not done. Perhaps I wasn't clear enough. My apologies. Let me clarify. What you are thinking of is probably forkProcess, not callProcess. forkProcess returns a ProcessID. callProcess returns an ExitCode.

(By the way, I don't know if forkProcess has fixed #1.)

The point of this package is that, "unix" does not provide high-level functions like readProcessWithExitCode or getDirectoryFilesRecursive. It never did. "process" and "directory" did provide them, but only for FilePath (String), and that's why I made this package.

In other words, we have readProcessWithExitCode for String and ByteString, and now we need readProcessWithExitCode for ShortByteString. It shouldn't be overly difficult. Some of the code in rawfilepath (this repo) may be translatable almost without any change.

When you look at the function name, readProcessWithExitCode, you'd immediately notice this is higher-level than the responsibility of the "unix" package. But we need this function somewhere. (I think functions like callProcess or readProcessWithExitCode are so obviously necessary if you are to do something practical with Haskell.) Do you think "filepath" would accept them? If not, we will need to make a new package.

Either way, I'm glad OsPath is here, and I'm willing to give any help I can.

[hasufell]

It never did. "process" and "directory" did provide them, but only for FilePath (String), and that's why I made this package.

Directory package is already migrated. Process not.

• https://github.com/haskell/process/issues/252
• https://hackage.haskell.org/package/directory-1.3.8.1/docs/System-Directory-OsPath.html

[woffs]

A bit off-topic maybe, but don't forget "hinotify".

[joeyh]

Note that base does not implement AFPP yet, so things like withFile are still needed from this library.

[hasufell]

Not sure I can follow. This library has nothing to do with AFPP. AFPP does not use RawFilePath.

Also:

• https://hackage.haskell.org/package/filepath-1.4.100.4/docs/System-OsPath-Encoding-Internal.html#v:withFilePathWin
• https://hackage.haskell.org/package/filepath-1.4.100.4/docs/System-OsPath-Encoding-Internal.html#v:withFilePathPosix

[xtendo-org]

Yeah well I think what joeyh really means is

• In order to avoid the issues with FilePath (filesystem encoding, performance, etc.) you need to use either RawFilePath (this package) or OsPath (AFPP)
• base provides neither, and for withFile, withFile (RawFilePath) is the only option
• (If base implemented AFPP, it would have implemented withFile for OsPath as well, which is what joeyh meant, I think)
• (But base unfortunately doesn't, so RawFilePath remains relevant)

There is no withFile for OsPath at the moment, am I right? The functions you linked seem to take FilePath (String), not OsPath (ShortByteString).

But implementing withFile for OsPath shouldn't be too difficult. At least it should be easier than callProcess for OsPath.

[hasufell]

There is no withFile for OsPath

That's the issue. Because that function doesn't make sense.

You have to distinguish between platforms when going to the original bytes, because they have fundamentally different shape (char vs wide char array).

Failure to do so will lead to broken code.

Can you explain precisely what the problem is?

[xtendo-org]

@hasufell Well, to make sure we're on the same page... Here's one scenario I can think of:

1. The programmer obtains a list (or array, or whatever) of files in a directory, using something like... Let's say getDirectoryFileList
2. The programmer wants to apply some logic for all files
3. The programmer uses withFile to obtain a file handle and interact with the file content

I think this is a pretty realistic use case. Linting, spell correcting, graphics texture file manipulation, and so on. RawFilePath allows this. The advantage of AFPP would be to let you write code that works on Windows as well.

The internal representation of the file content would matter, because that's the sequence of bytes the programmer is actually manipulating. But the internal representation of the file path (char vs wide char array) shouldn't matter, because the list is not constructed by the programmer. It's from the OS.

It could be a char array or a wide char array, and the programmer doesn't care; What is returned by getDirectoryFileList will simply be passed to withFile. The path bytes are intact.

Hopefully withFile for OsPath makes a bit more sense now?

[hasufell]

Oh... I confused withFile with withFilePath.

If you had read the blog post I linked, you'd know withFile is indeed already implemented: https://hackage.haskell.org/package/file-io-0.1.0.1/docs/System-File-OsPath.html#v:withFile

[xtendo-org]

Oh well good. Excellent. Thanks.

@joeyh Check it out!