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

Decide how to represent pathnames #124

Closed
1 task
talex5 opened this issue Jan 3, 2022 · 3 comments
Closed
1 task

Decide how to represent pathnames #124

talex5 opened this issue Jan 3, 2022 · 3 comments
Labels
api API design decision

Comments

@talex5
Copy link
Collaborator

talex5 commented Jan 3, 2022

At the moment, paths in Eio are strings, which are used in the context of some base directory. e.g.

Eio.Dir.with_open_in cwd "foo/input.dat" (fun flow -> ...)

This should work well on most systems, but we need to think about how to support Windows too.

Possibilities include:

  • Using Unix path strings everywhere and providing a way to import and export Windows paths.
  • Using an abstract type for paths.

The Fpath library encodes lots of knowledge about Windows paths. It probably can't be used directly because its paths behave differently depending on the host platform (preventing e.g. a program running on Linux from creating paths that are to be used on Windows). The path rules should probably be per-filesystem instead.

@talex5 talex5 mentioned this issue Jan 3, 2022
9 tasks
@talex5 talex5 added the api API design decision label Jan 10, 2022
@samwgoldman
Copy link

My 2¢ here is to leave paths as strings. Getting paths "right" for all use cases doesn't seem possible, and having a flexible low-level API somewhere, even if it opens up the possibility for errors, seems valuable to me.

For Flow, we have the need to share paths between platforms. These are relative paths, using the / path separator. We only support Windows systems that transparently support the / path separator, so we can just pass these paths into Windows APIs without transforming them.

However, we do build wrappers around the various paths, to ensure they are not mishandled. But this is an application-layer concern for us. We take the strings returned by system calls into the appropriate (unboxed) wrapper type and coerce back into strings as needed.

@talex5
Copy link
Collaborator Author

talex5 commented Mar 30, 2023

Thanks, that makes sense. And I see that DOS has always supported / as a path separator anyway:

https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-is-the-dos-path-character

@talex5 talex5 closed this as completed Mar 30, 2023
@avsm
Copy link
Contributor

avsm commented Mar 31, 2023

Do you have a link to your path wrapper library, @samwgoldman? It'd be interesting to contrast it with Fpath and Python's Pathlib. I agree that keeping strings at a low-level in Eio is a reasonable for Eio 1.0.

@talex5 talex5 mentioned this issue Jul 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api API design decision
Projects
None yet
Development

No branches or pull requests

3 participants