Bifunctor support? about directory-tree

[jberryman]

Yeah, I definitely understand your use case. A possibly better (in the context of the library) way to do this might be to change Dir to:

  | Dir {
        dir     :: a      -- formerly `name :: FileName`
      , contents :: [DirTree a b]
    }

And this could mirror our functions that already work on and manipulate DirTree FileName, which would instead work on DirTree FileName FileName.

Then we might want to simply remove the records (since those partial records aren't very nice). And add a function (a shim for users of name):

name :: DirTree FileName a -> FileName

And I think rather than a BiFunctor instance, we might provide a newtype wrapper like:

-- not a great name:
newtype DirectoryView files dirs = DirectoryView (DirTree dirs files)

And provide all the relevant instances we can for that type.

Let me know what you think and let's stew on this for a bit.

[hasufell]

That sounds interesting, but I have two thoughts about that:

• about name :: DirTree FileName a -> FileName: I'd go so far to consider making FileName a newtype (API breakage :/ )... because it is just String and our dir record can have Strings of arbitrary meaning and isn't as explicit as the previous name :: FileName record anymore
• I'm not entirely sure if this wouldn't limit the API for my use case (and possibily others), since any library function that wants to operate on directory and file names, must have the type DirTree FileName FileName type if I am not mistaken? Then people would have to create wrappers around those functions if they want to use it, because their types might be different, since they want to use the dir :: a record for something else. I think the dropTo function for example would be affected by this.

[jberryman]

dropTo would have the type

dropTo :: FileName -> AnchoredDirTree Filename a -> Maybe Filename (AnchoredDirTree a)

other functions could be polymorphic in that new first variable.