Proposal: Define UTF-8 to be the encoding of Haskell source files

[Duncan Coutts]

On Wed, 2011-04-06 at 16:09 +0100, Ben Millwood wrote:
> On Wed, Apr 6, 2011 at 2:13 PM, Duncan Coutts
> <duncan.coutts at googlemail.com> wrote:
> >
> > Interoperability Guidelines
> > ========================
> >
> > [...]
> >
> > To find a source file corresponding to a module name used in an import
> > declaration, the following mapping from module name to OS file name is
> > used. The '.' character is mapped to the OS's directory separator
> > string while all other characters map to themselves. The ".hs" or
> > ".lhs" extension is added. Where both ".hs" and ".lhs" files exist for
> > the same module, the ".lhs" one should be used. The OS's standard
> > convention for representing Unicode file names should be used.
> >
> 
> This standard isn't quite universal. For example, jhc will look for
> Data.Foo in Data/Foo.hs but also Data.Foo.hs [1]. We could take this
> as an opportunity to discuss that practice, or we could try to make
> the changes to the report orthogonal to that issue.

Indeed. But it's true to say that if you do support the common
convention then you get portability. This does not preclude JHC from
supporting something extra, but sources that take advantage of JHC's
extension are not portable to implementations that just use the common
convention.

> In some sense I think it's cute that the Report doesn't specify
> anything about how Haskell modules are stored or represented, but I
> don't think that freedom is actually used, so I'm happy to see it go.
> I'd think, though, that in that case there would be more to discuss
> than just the encoding, so if we could separate out the issues here, I
> think that would be useful.

It's not going. I hope I was clear in the example text that the
interoperability guidelines were not forcing implementations to use
files etc, just that if they do, if they uses these conventions then
sources will be portable between implementations.

It doesn't stop an implementation using URLs, sticking multiple modules
in a file or keeping modules in a database.

Duncan