Re: Proposal: System.FilePath: current directory should be ".", not ""
Ben Moseley wrote:
Duncan Coutts wrote:
My intuition with file paths in Cabal, is that this distinction would catch more bugs. Ideally cabal's building code would be independent of the current directory, but the fact that relative paths get automagically completed to being relative to the current directory means that it's very easy to break this property.
[...]
There are various other distinctions one could try to make, the question becomes which type distinctions are useful and when does it just become too much.
I think this is a very important point. It's definitely a balancing act. I have ondered whether even capturing Abs/Rel was overkill, but my current feeling (not yet based on much real-world experience) is that it is worth it.
Having done a lot of system administration and metaprogramming of system administration, I can certainly say that making the relative/absolute distinction is helpful for tracking down bugs. From the same set of experience I'd say that Duncan's incomplete/complete distinction would be even more helpful. With a lot of sysadmin metaprogramming (which includes package installers) what people are really working on is grafting different trees together. It's important to distinguish which paths/trees are being created and don't yet refer to an actual or potential file on the disk, from those paths/trees which refer to actual/potential files on the disk. To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing. With the complete/incomplete distinction we distinguish names which aren't yet grounded from names that refer to files, regardless of where they're mounted. With the relative/absolute distinction we don't know when a path is finished being constructed, and we also have no real vocabulary for expressing paths relative from some point other than the current directory. Most sysadmins don't seem to realize they're doing tree grafting when they mess with this stuff, so I can see why it might seem foreign, but viewing it that way really does help clean code up and find bugs. Tree grafting also forms a monad, which could be helpful for some folks. -- Live well, ~wren
Thanks for the comments - I'll look at incorporating them into pathtype. (I've taken the liberty of filing this along with Duncan's comments as: http://trac.haskell.org/pathtype/ticket/2). --Ben On 16 Nov 2009, at 08:20, wren ng thornton wrote:
Ben Moseley wrote:
Duncan Coutts wrote:
My intuition with file paths in Cabal, is that this distinction would catch more bugs. Ideally cabal's building code would be independent of the current directory, but the fact that relative paths get automagically completed to being relative to the current directory means that it's very easy to break this property.
[...]
There are various other distinctions one could try to make, the question becomes which type distinctions are useful and when does it just become too much.
I think this is a very important point. It's definitely a balancing act. I have ondered whether even capturing Abs/Rel was overkill, but my current feeling (not yet based on much real-world experience) is that it is worth it.
Having done a lot of system administration and metaprogramming of system administration, I can certainly say that making the relative/absolute distinction is helpful for tracking down bugs. From the same set of experience I'd say that Duncan's incomplete/complete distinction would be even more helpful.
With a lot of sysadmin metaprogramming (which includes package installers) what people are really working on is grafting different trees together. It's important to distinguish which paths/trees are being created and don't yet refer to an actual or potential file on the disk, from those paths/trees which refer to actual/potential files on the disk.
To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing. With the complete/incomplete distinction we distinguish names which aren't yet grounded from names that refer to files, regardless of where they're mounted. With the relative/absolute distinction we don't know when a path is finished being constructed, and we also have no real vocabulary for expressing paths relative from some point other than the current directory.
Most sysadmins don't seem to realize they're doing tree grafting when they mess with this stuff, so I can see why it might seem foreign, but viewing it that way really does help clean code up and find bugs. Tree grafting also forms a monad, which could be helpful for some folks.
-- Live well, ~wren _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Mon, 2009-11-16 at 03:20 -0500, wren ng thornton wrote:
To think about why this distinction is helpful, consider where all we may want to attach the paths/trees we're creating. The two obvious places are / and . but there are other options too. Most programs support some notion of a $PATH variable or allow flags to specify the target directory for reading or writing.
This is a good point. Once you've got a search $PATH of some sort then "./foo" and "foo" are actually different. "./foo" is a complete path and refers to the file (or directory) foo in the current directory while "foo" is an incomplete path that the function will try to complete by looking for a file in each of the search directories. So under a complete/incomplete distinction, a function like exec takes Either Complete Incomplete, where the incomplete ones get the search path treatment and the complete ones do not. Duncan
participants (3)
-
Ben Moseley -
Duncan Coutts -
wren ng thornton