grammar fixes and comments

en/lessons/basics/modules.md

@@ -115,16 +115,16 @@ wrapIdentity = Identity
 
 There is an important piece of syntax, which comes before module syntax, and
 that is language extensions. We won't exhaustively go over the functionality of
-individual extensions do here, but it is valuable to be able to recognize them.
+individual extensions here, but it is valuable to be able to recognise them.
 At a high level language extensions change and extend the behaviour of GHC. The
-example below `OverloadedStrings` changes the behaviour of the built in string
+example below `OverloadedStrings` changes the behaviour of the built-in string
 syntax (double quotes) to be more general so that you can use different types /
 representations of strings that behave in similar ways.
 
-> Note: If the way that Haskell deals with strings is confusing right now,
+> __Note__: If the way that Haskell deals with strings is confusing right now,
 > don't worry. Pretty much every new haskeller goes through this. We choose
 > to introduce it now because language extension syntax is important to
-> recognize and OverloadedStrings is probably the most common language
+> recognise and OverloadedStrings is probably the most common language
 > extension. String types and language extensions will be covered in more
 > depth later!
 
@@ -153,12 +153,18 @@ stringlikePackedBinary = "string"
 
 ## Import Syntax
 
-Modules can be listed as a dependency within other modules. You might not want
-to think of imports in terms of the dependency chain they imply, in this case
-an import can be though of as bringing some entities from the imported module
-into the scope of your current module. It is necessary to have these
-declarations at the top of a file, below the module declaration and above any
-top level declarations.
+Modules can be listed as a dependency within other modules using the `import`
+keyword. It is necessary to have these declarations at the top of a file,
+below the module declaration and above any top level declarations.
+
+At this point I'd like to clarify the two mental models we use to think about
+modules and imports. The model we introduced in the beginning of this lesson is
+a graph of dependencies, but it can be more intuitive to think of an import in
+terms of the entities it brings into scope.  Both mental models are correct.
+Thinking of an import as an edge in a dependency chain is useful when trying to
+reduce compile time bottlenecks or debug an import cycle. Thinking in terms of
+the entities being brought in to scope is useful as a user of the imported
+module, and also when trying to prevent namespace collisions.
 
 This is an "open" import, and it brings all entities exported by the module into
 scope.