[Feedback requested]: -fhelpful-import-errors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Feedback requested]: -fhelpful-import-errors

Tom Sydney Kerckhove
Hi,

I raised a ticket to request a new feature: -fhelpful-import-errors.

This flag should enable helpful errors if there are typo's in the
internal imports of your projects.

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.

Thank you for your time.

--
Tom Sydney Kerckhove
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: [Feedback requested]: -fhelpful-import-errors

Sven Panne-2
2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove <[hidden email]>:
[...] 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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: [Feedback requested]: -fhelpful-import-errors

Simon Peyton Jones

Best in the ticket https://ghc.haskell.org/trac/ghc/ticket/11418#comment:27, I transferred your comment there

 

S

 

From: Glasgow-haskell-users [mailto:[hidden email]] On Behalf Of Sven Panne
Sent: 16 February 2016 18:03
To: [hidden email]
Subject: Re: [Feedback requested]: -fhelpful-import-errors

 

2016-02-16 18:12 GMT+01:00 Tom Sydney Kerckhove <[hidden email]>:

[...] 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.


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users