More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Merijn Verstraaten]

Hey,

I'm not really happy with an explicit extension list passed through flags, as it seems far to manual. It doesn't strike me as a very significant problem as my current work-in-progress patch only resorts to scanning the directory listing if none of the existing extensions are found.

It seems unlikely that extremely large directories are in the search path. I don't think we're expecting anyone to have thousands of files in their module directories (and even thousands would take 0 time to scan...). We already try all search paths during probing so the extra overhead from large number of search paths shouldn't be substantially more than we have now.

As for the weird FS support, I really don't think it's GHC's job to support people doing ridiculous things like "compiling on a filesystem that doesn't support directory listings", I mean, come on!

To be honest, I consider both directories with huge numbers of files (keep in mind, we'd only scan the actual module sub-directory AND that we'd need to run into directories with tens if not hundreds of thousands files to notice any real slowdown) and weird filesystems that don't support directory listing cases of "so don't do that, then". Especially since these are only problems for users using non-standard module extensions.

Cheers,
Merijn

> On 20 Nov 2014, at 2:40, Sven Panne <svenpanne at gmail.com> wrote:
> 2014-11-20 9:36 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:
>> [...] With your extensions it will have to read the directory contents. In
>> most situations, that should be fine, but it might cause minor
>> inconveniences with very large directories, many search paths (-i flags)
>> and/or very weird file systems (compiling from a FUSE-mounted
>> HTTP-Server that does not support directory listing? Would work now...)
> 
> Hmmm, IMHO reading directory contents is not a good idea for a
> compiler, for just the reasons you mentioned.
> 
>> A fixed set of extensions (e.g. just "md" and "tex") would avoid this
>> problem, but goes against the spirit of the proposal.
> 
> I think we can get the best of both worlds by adding a compiler flag,
> e.g. --literate-extensions=md,tex. This way the compiler still has to
> probe only a finite set of filenames *and* we are still flexible.