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

Carter Schonwald carter.schonwald at
Tue Nov 25 22:20:31 UTC 2014

Did you try measuring on eg, edwardk's gl package?

On Thu, Nov 20, 2014 at 12:52 PM, Merijn Verstraaten <merijn at
> wrote:

> 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> wrote:
> > 2014-11-20 9:36 GMT+01:00 Joachim Breitner <mail at>:
> >> [...] 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.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list