You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
moduleSystem.OsPath.Componentwhere--| A component of a filepath, i.e. a filpath that does not contain any path separators.newtypeComponent=Component (SliceOfOsPath)
-- This should probably live in the os-string packagedataSliceOf=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?
The text was updated successfully, but these errors were encountered:
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:
extract the ShortByteString
convert it to Data.Bytes.Bytes
run the parser
convert back to ShortByteString
For that we would need parser implementations for Bytes, which does not exist yet, afais.
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:
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?
The text was updated successfully, but these errors were encountered: