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

On Wed, 2011-04-06 at 16:09 +0100, Ben Millwood wrote:

On Wed, Apr 6, 2011 at 2:13 PM, Duncan Coutts 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