Abstract FilePath Proposal

[David Fox]

On Sat, Jun 27, 2015 at 6:37 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2015-06-27 at 14:56:33 +0200, David Fox wrote:
>
> [...]
>
> > ​I've had success with a slightly different "How":
>
> What was your concrete use-case btw?
>
> > Phase 1: Replace FilePath with a type class, with instances for the old
> > FilePath (i.e. String) and the new implementation.
>
> what would that comprise in the FilePath case?
>
> I assume adding a transitional class whose methods are not exposed (and
> whose typeclass name is exported from some GHC-specific internal-marked
> module)? i.e.
>
>   class IsFilePath a where
>     privateToFilePath :: a -> FilePath
>     privateFromFilePath :: FilePath -> a
>
>   instance IsFilePath FilePath where
>     privateToFilePath   = id
>     privateFromFilePath = id
>
>   instance IsFilePath [Char] where
>     privateToFilePath   = System.IO.toFilePath
>     privateFromFilePath = System.IO.fromFilePath
>
> ?
>
> as well as changing a lot of type-sigs in base & filepath from
> e.g.
>
>   writeFile :: FilePath -> String -> IO ()
>   openTempFile :: FilePath -> String -> IO (FilePath, Handle)
>
> to
>
>   writeFile    :: IsFilePath a => a -> String -> IO ()
>   openTempFile :: IsFilePath a => a -> String -> IO (a, Handle)
>
>
> ?
>
> > Phase 2:  Wait until a suitable amount of hackage builds without the
> string
> > instance.
>
> I can see Stackage helping with that by using a custom GHC which lacks
> the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2
> could be
> accomplished within one year for the Stackage-subset of Hackage.
>
> > Phase 3: Deprecate the String instance - move it to an old-filepath
> package.
> >
> > Phase 4: Replace the type class with the new implementation
>
> I assume this means getting rid again of the typeclass, and changing the
> type-sigs back to i.e.
>
>   writeFile :: FilePath -> String -> IO ()
>   openTempFile :: FilePath -> String -> IO (FilePath, Handle)
> ​
> (but now with with the new opaque `FilePath`)?
>
> > This way the new implementation is available immediately, packages can
> > begin converting at once, benefits can be assessed.
>
> This scheme seems feasible at first glance, as long as the typeclass
> doesn't start spreading across packages and find its way into type-sigs
> (in which case it'd become more disruptive to get rid of it
> again). Otoh, I'm not sure (assuming I understood how your scheme works)
> it can be avoided to have the typeclass spread, since if not every API
> that now has `FilePath` arguments in their type-sigs gets generalised to
> have `IsFilePath a => a` arguments instead, we can't reach the goal of
> "Phase 2".
>
> But I suspect that I didn't fully understand how your proposed
> transition scheme works exactly... so please correct me where I got it
> wrong!
>

​You are right, your approach is more appropriate for use by a community.​
 I missed some of the problems that would arise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150627/0115017c/attachment.html>