prelude.md

@@ -25,9 +25,10 @@ Thus it might be useful to trim the Prelude down to the bare minimum possible.
 1. Remove entities that clash with other common libraries, which would otherwise require `import Prelude hiding`.  For example, a function called `catch` is also exported by `Control.Exception`, `take/drop` are also exported by `Data.Sequence`.  A list of these can easily be constructed.
 1. Remove entities that are used in fewer than N% of modules (measure as much code as we can get our hands on, choose some appropriate N).
 1. Decide what to keep.
+1. Remove the implicit import of the Prelude in its entirety.  Where a syntactic desugaring rule currently uses an entity from the Prelude, the new interpretation is that it uses whatever binding of that entity is in scope - if there is no such entity in scope, it is an error.  For compatibility, the current Prelude can continue to be made available as an explicit import, so that the only change required to fix existing code is `import Prelude`.  Indeed, an implementation may choose to provide a compile-time option like `-fimplicit-prelude`, the inversion of ghc's `-fno-implicit-prelude`, to avoid the need to change old code at all.
 
 
-For the record I (Simon M.) support doing at the very least (1), and I'm interested in measuring code along the lines of (2) so that we can find out what things are hardly ever used.  (3) is rather less conservative.
+For the record I (Simon M.) support doing at the very least (1), and I'm interested in measuring code along the lines of (2) so that we can find out what things are hardly ever used.  (3) is rather less conservative.  (4) is Malcolm's idea.
 
 
 ## Comment