<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 14 Nov 2009, at 14:02, Duncan Coutts wrote:</div><blockquote type="cite"><div>So the type distinctions you are making are:<br><br> * whether a path refers to a file or to a directory<br> * whether a path is relative or absolute<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div>Yep, that's the idea.<br><br><blockquote type="cite"><div>By relative and absolute it looks like you mean whether it starts with<br>the root "/" vs not. So "foo/bar.txt" and "./foo/bar.txt" are both<br>considered as relative.<br></div></blockquote><div><br></div>Yes.</div><div><br></div><div><blockquote type="cite"><div>So in the similar design I was working on, instead of distinguishing<br>relative and absolute, I distinguish incomplete and complete. I<br>initially started with the relative/absolute distinction and moved onto<br>this one. It'd be interesting to see which is most useful in practise.<br><br>What I mean by complete is a path referring to an actual file/dir that<br>you could pass to a system call. This means they are anchored to some<br>point the system knows about, such a "." the current directory or "/" or<br>"C:\".<br><br>Then an incomplete path is one that is not anchored. Incomplete paths<br>become complete by </> them to a existing complete one (including the<br>current dir).<br><br>So the difference between this complete/incomplete notion and<br>relative/absolute is for paths that are relative to the current<br>directory.<br><br>You would say "Main.hs" :: RelFile <br><br>and<br><br>readFile :: AbsRelClass ar => FilePath ar -> IO String<br><br>and so readFile "Main.hs" is ok, and reads the file "./Main.hs" in the<br>current directory.<br><br>I would probably say, "Main.hs" :: IncompleteFilePath<br><br>(though I think I used somewhat shorter type names than that!)<br><br>and <br><br>readFile :: CompleteFilePath -> IO String<br><br>and thus readFile "Main.hs" is not well typed, instead it would be:<br><br>readFile (currentDir </> "Main.hs")<br><br>because that gives us a complete path, and if we want that to be rooted<br>at the processes' current directory, then we do so explicitly.<br></div></blockquote><div><br></div><div>Ah, ok, I see. I can see the attraction to that.</div><br><blockquote type="cite"><div>My intuition with file paths in Cabal, is that this distinction would<br>catch more bugs. Ideally cabal's building code would be independent of<br>the current directory, but the fact that relative paths get<br>automagically completed to being relative to the current directory means<br>that it's very easy to break this property. </div></blockquote><div><br></div>Interesting.</div><div><br></div><div>One possible approach with pathtype as it stands would be a wrapper</div><div>module which hides "readFile :: AbsRelClass ar => FilePath ar -> IO String"</div><div>and exposes it only at the restricted type:</div><div>"readAbsFile :: AbsFile -> IO String; readAbsFile = readFile".</div><div>This blocks accidental reading of relative files and clients are forced to use</div><div>something like 'makeAbsoluteFromCwd'.</div><div><br></div><div>I don't think this is exactly the same as what you're suggesting (it doesn't</div><div>permit the "completion" process to be separated from the reading), but I think it</div><div>would be a way to catch some of the same bugs?</div><div><br><blockquote type="cite"><div>There are various other distinctions one could try to make, the question<br>becomes which type distinctions are useful and when does it just become<br>too much. </div></blockquote><div><br></div><div>I think this is a very important point. It's definitely a balancing act. I have </div><div>ondered whether even capturing Abs/Rel was overkill, but my current feeling</div><div>(not yet based on much real-world experience) is that it is worth it.</div></div><div><br></div><div>Cheers,</div><br><div>--Ben</div><div><br></div></body></html>