[Haskell-cafe] RE: ANN: System.FilePath 0.9

Udo Stenzel u.stenzel at web.de
Wed Jul 26 13:41:58 EDT 2006


Duncan Coutts wrote:
> On Wed, 2006-07-26 at 15:29 +0200, Udo Stenzel wrote:
> 
> > Exactly.  I believe, a FilePath should be an algebraic datatype.
> 
> We've had this discussion before. The main problem is that all the
> current IO functions (readFile, etc) use the FilePath type, which is
> just a String.

So what's better?

- use an ADT (correct and portable by construction), convert to String
  when calling the IO library

- fumble with Strings, use an unholy mix of specialized and general
  functions, trip over a corner case


> So a new path ADT is fine if at the same time we provide
> a new IO library.

We should just wrap the old API, filePathToString any parameters and
liftIO the function while we're at it.


> That's another portability headache - file name string encodings.
> Windows and OSX use encodings of Unicode. Unix uses strings of bytes.

Indeed.  There are two ways out:

- declare that Unix uses Unicode too, take the appropriate conversion
  from the locale

- parameterize the FilePath ADT on the character type, you get (FilePath
  Word16) on Windows (which uses UCS-2, not UCS-4 and not UTF-16) and
  (FilePath Word8) on Unix; provide conversions from/to (FilePath
  String).

I tend towards the second option.  It at least doesn't make anything
worse than it already is.  It's also irrelevant, since pretending the
issue doesn't exist works equally well with an ADT.

> My point is it's not quite as simple as "just making an ADT".

Mine is that it is :)  Moreover, a path already has internal structure.
Those string manipulating functions either reconstruct the structure,
then operate on that, then encode it back into a string or implement an
approximation to that.  The latter leads to surprises and making the
former explicit can never hurt.  Heck, NO library fumbles with strings,
neither parsers nor pretty printers nor Network... why should a FilePath
be different?


Udo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060726/4d171c63/attachment.bin


More information about the Haskell-Cafe mailing list