[Haskell] System.FilePath survey

[Bulat Ziganshin]

Hello David,

Monday, February 06, 2006, 4:12:41 PM, you wrote:

>> well, if FilePath should be ADT, then:
>> 1) all operations that returns filenames (getFileContents, anything
>> more?) should return this ADT instead

DR> You mean getDirectoryContents?
DR> getCurrentDirectory, getHomeDirectory, getTemporaryDirectory, etc.
DR> canonicalizePath.

DR> Actually couldn't they all be made polymorphic?

yes, of course they should! now i myself experiment with that
sort of polymorphic interfaces. for example, "getFileSize" can return
any Integral. it's a user decision, whether he needs to receive Int,
Integer or say Word64 in answer. this have some limitations, namely
that we need to add type signatures sometimes (although this can be
addressed in future Haskell by extending the "default" directive) and
that this can be slower/generate more code

DR> getDirectoryContents :: FilePath p => IO p

DR> class FilePath p where
DR>   fromADT :: ADT -> p
DR>   toADT :: p -> ADT

DR> (where I have declined naming the ADT)

yes, we can define all interfaces using this class, while internally
all these functions will convert parameters to the type they need:

convertADT = fromADT . toADT    -- like "fromIntegral" definition

getDirectoryContents :: (FilePath dir, FilePath file)
                     => dir -> IO [file]
getDirectoryContents dir = do
   let (dirStr :: String) = convertADT dir
   ....
   return (map convertADT filelist)

>> 2) this ADT should support conversion to/from String (for interaction
>> with users) and to/from [Word8] (to send these values across
>> storage/network). Of course, these conversions should be as exact and
>> revertible as possible, i think that at least we can make guarantee
>> for ascii chars

DR> Probably we'd also want a withCString equivalent that works with the ADT,
DR> for use when working with the FFI.  True, you could do the conversion via
DR> [Word8], but that's ugly (and potentially inefficient, depending how the
DR> ADT is stored internally).

probably, this ADT should be different for different OSes and just be
the same as filenames representation native for this OS. that
guarantee us that any filenames possible in this OS will be
representable and minimal overhead of OS calls. if someone need
another concrete representation - he would convert this ADT to the
concrete datatype he need, be it String, [Word8], "UArray Int Word8" or
FastPackedString 

>> 3) all operations that receives filenames should accept a _class_
>> which includes String/[Word8]/this ADT

DR> That would be nice, but I suspect not strictly necessary.

i mean "all operations in standard library". it's easy to do, at least
while we don't count efficiency problems

>> of course, this means incompatible changes in the APIs, so it's better
>> to introduce new fucntions that  returns ADT/accepts class  with a new
>> names

DR> I don't know.  I'd lean towards not introducing new function names.  The
DR> point of accepting the class would be that existing code would continue to
DR> work.  The only code that would be broken would be code that uses
DR> getFileContents, which is a sufficiently small minority of code that I
DR> would say just let it break.  You'd leave the Haskell 98 Directory module
DR> returning String, but I'd vote to make System.Directory.

really, promoting all operations to using class will be enough to not
break compatibility with any existing code

-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com