[Feedback requested]: -fhelpful-import-errors
Sven Panne
svenpanne at gmail.com
Tue Feb 16 18:02:37 UTC 2016
2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove <syd.kerckhove at gmail.com>:
> [...] As suggested by `thomie`, I created a design proposal at
> https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError
> and am now looking for feedback.
[ Not sure if the feedback should be submitted here on in the corresponding
ticket... ]
Just a few quick remarks:
* Whatever you do, never walk the file system tree up or down in an
uncontrolled way, this will kill basically all benefits and is a
show-stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so
*horribly* slow when used that way that the walks will probably dominate
your compilation time. And even under Linux it's not uncommon to have a few
dozen directory levels and hundreds of thousands of files below our cwd:
Just check out a few repositories, have some leftovers from compilations,
tons of documentations in small HTML files etc., and this sums up quickly.
Git walks up the tree, but only looking for a specific directory and will
e.g. not cross mount points under normal circumstances. This is probably
the limit of what you can do.
* Caching between runs will be tricky: How will you invalidate the
cache? People can (and will :-) do all kinds of evil things between runs,
so how can you (in-)validate the cache quicker than re-scanning the file
system again?
* As a general rule to keep in mind during the design: Successful
compiler runs should not pay a price. It's OK if things are a little bit
slower when an error occurs, but the main use case is successful
compilation. This is a bit like exceptions in most programming language
implementations: They are more or less for free when you don't use them
(yes, they have a cost even then because they complicate/invalidate some
compiler optimizations, but let's forget that for now), and are often
costly when you actually raise them.
Just my 2c,
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160216/dc679b74/attachment.html>
More information about the Glasgow-haskell-users
mailing list