Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A type for filepath components #234

Open
mmhat opened this issue Jun 24, 2024 · 2 comments
Open

A type for filepath components #234

mmhat opened this issue Jun 24, 2024 · 2 comments

Comments

@mmhat
Copy link

mmhat commented Jun 24, 2024

While working on commercialhaskell/path#192 I noted that it might be helpful to have a separate type for a path component for some use cases. Since we have the nice AFPP-style APIs that is nothing more than a slice of the underlying filepath:

module System.OsPath.Component where

-- | A component of a filepath, i.e. a filpath that does not contain any path separators.
newtype Component = Component (SliceOf OsPath)

-- This should probably live in the os-string package
data SliceOf = SliceOf
  { sliceOfOffset :: {-# UNPACK #-} Int -- ^ The offset where the slice starts in bytes
  , sliceOfLength :: {-# UNPACK #-} Int -- ^ The length of the slice in bytes
  , sliceOfFilePath :: {-# UNPACK #-} OsPath -- ^ The underlying filepath
  }

As far as I am concerned I am only interested in an addition for the AFPP-style filepaths.

Would the contribution of such a type and the API for working with it accepted?
Is a CLC proposal needed?

@hasufell
Copy link
Member

I have though about it, but it would require re-implementing most of the OsString API, similar to Data.Bytes. That is considerable work (also mind that we have a custom Word16 implementation for windows).

And it is not yet clear to me what the advantage is. We're usually not dealing with large data when we get OsString from OS API back... reading files does not yield OsString. It is rather things like getting env variables, program arguments or filepaths.

Where this becomes interesting is parsers (which rely on slicing to be efficient). But my idea there would be to:

  1. extract the ShortByteString
  2. convert it to Data.Bytes.Bytes
  3. run the parser
  4. convert back to ShortByteString

For that we would need parser implementations for Bytes, which does not exist yet, afais.

@Bodigrim

@Bodigrim
Copy link
Contributor

I don't think there is much benefit from sliced strings for os-string / filepath use case.

A parser on Bytes from byteslice would be a helpful development, yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants