# Reviving the Abstract FilePath Proposal (AFPP) in user-space

**URL:** <https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344>\
**Category:** Haskell Foundation\
**Created:** [April 10, 2021, 2:12pm UTC](https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344 "2021-04-10T14:12:10Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![hasufell](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/hasufell/32/1250_2.png) [@hasufell](https://discourse.haskell.org/u/hasufell)\
**Post date:** [April 10, 2021, 2:12pm UTC](https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344/1 "2021-04-10T14:12:10Z")

</div>

## Introduction

For anyone who isn’t familiar, the original Abstract FilePath Proposal is here: [https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path)

In short, it tries to get rid of the `type FilePath = String` mistake for various reasons.

## Proposal

Since it’s unlikely that this proposal will ever make it into base, the alternative proposal is this:

1. write a library that implements the proposal as a new type `AbstractFilePath` with various utility functions (as opposed to replacing `FilePath`)
2. Patch `unix` package to provide `System.Posix.Files.AbstractFilePath` variants (we already have them for `ByteString`)
3. Patch `Win32` package to provide a similar variant
4. write libraries using these types (`filepath` and `directory` aren’t forced to migrate)

## Existing work

I’ve already taken a stab at 1:

- [https://github.com/hasufell/abstract-filepath](https://github.com/hasufell/abstract-filepath)
- [rendered documentation](https://files.hasufell.de/jule/abstract-filepath/)

The big advantage for me personally is that there are quite a few use cases where I can get away without knowing the filename encoding. But I can only ignore the encoding if we’re dealing with untampered byte strings. In case this will move forward, I’m planning to migrate [some of my libraries](https://github.com/hasufell/hpath) to this type, which are alternatives to `filepath` and `directory` I currently use in all my projects.

## Discussion

The main question is basically if `unix` and `Win32` would accept patches for this as **new** API variants. One of the reasons of AFPP is to not roundtrip through String or ByteString, so there’s not much point if we need to convert from unpinned ShortByteString before the syscall.

I think this proposal doesn’t really need complete consensus, since it’s backwards compatible and just an alternative API. It won’t change base, it won’t break existing code and it won’t force anyone to use it, if they’re not interested. And even if someone uses a library utilizing `AbstractFilePath` against their will, they can still convert to String and use the other APIs.

I’m also interested to hear opinions about the current implementation. Please see the [rendered documentation](https://files.hasufell.de/jule/abstract-filepath/).

I’d also like to hear @snoyberg’s opinion, specifically, since he’s one of the authors of the original proposal.

---

_[View the full topic](https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344)._