type-directed-name-resolution.md

@@ -8,10 +8,10 @@
 <th>[ExistingRecords](existing-records)</th></tr></table>
 
 
-See email thread at [ http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723](http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723)
+See also
 
-
-Right at the end of the page is a straw poll about the proposal.
+- email thread at [ http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723](http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723)
+- The [ publicly-editable TDNR discussion page](http://haskell.org/haskellwiki/TypeDirectedNameResolution), and straw poll
 
 ## Exploiting the power of the dot
 
@@ -123,7 +123,7 @@ The basic design is simple:
 
   For example, `a`, `a.f` and `a.f.g` are atoms.
 
-- The dynamic semantcs of `a.f` is simply reverse application `(f a)`.
+- The dynamic semantics of `a.f` is simply reverse application `(f a)`.
 
 - Unlike normal unqualified variable occurrences, it is legal for there to be many `f`'s 
   in scope.  To resolve which one is intended, find the type of `a`, and the type of all 
@@ -150,7 +150,7 @@ I have deliberately used dot "`.`" for this feature, for several reasons:
 - Selecting a field from a record is a particularly convenient special case, 
   and the standard notation for that is "r.f".
 - TDNR is doing the same job as Haskell's existing qualified names, 
-  so it makes sense to use the sane notatoin.
+  so it makes sense to use the sane notation.
 
 
 Of course, there is a problem: Haskell already uses dot for (a)
@@ -259,7 +259,7 @@ Notice that, although record field names work great with TDNR, nothing
 requires the "x" in "a.x" to be a record field name.  The function "x"
 can be any old function whose type looks like "*t1 → t2*".  So the
 first argument of a curried function is special.  For example,
-consider a finite map module with signaturs like this:
+consider a finite map module with signatures like this:
 
 ```wiki
 data Map k v
@@ -322,7 +322,7 @@ because that would define two top-level functions, both called `x`.
 (And similarly `y`.)  But we probably really want to allow this.  The
 problem is that you could then *only* refer to `x` and `y` using
 TDNR, and I rather dislike that; I would prefer TDNR to be a convenient
-abbrevation for something one could write more verbosely.  If you
+abbreviation for something one could write more verbosely.  If you
 like, what is their "original name"?
 
 
@@ -351,7 +351,7 @@ Do we want to allow this?
 That is, do we want to allow two top-level functions, both called
 `get`?  Arguably yes: if we allow both S and T to be defined in the
 same module, even though they have the same field names,
-it'd make sene to allow their accessor functions to
+it'd make sense to allow their accessor functions to
 defined too.  
 
 
@@ -359,7 +359,7 @@ But, again I could only refer to them using TDNR and, worse, there is
 nothing in general to force them to have types that are amenable to
 TDNR.  This latter is different to record fields (whose types are
 inherently suitable).  So I propose to allow a module to contain
-muliple types with the same field; but not muliple functions with the
+muliple types with the same field; but not multiple functions with the
 same name.
 
 ## Record syntax
@@ -391,22 +391,3 @@ and means that `(.x) f` is equivalent to `f.x`.  The syntax and meaning is consi
 
 
 What about `(.x.y)`?  Does that expand to `(\f -> f.x.y)`?
-
-# Straw poll
-
-
-It's hard to gauge how much people like proposals like this, so let's try the experiment of collecting votes here:
-
-
-Names of people who would positively like to see TDNR happen (say briefly why)
-
-- Simon PJ (I wrote the proposal)
-
-
-Names of people who think that on balance it's a bad idea
-
-- fill in here
-
-## Other comments
-
-*Add your own comments here*
\ No newline at end of file