Changes between Version 7 and Version 8 of TypeDirectedNameResolution

Timestamp:

11/17/09 10:00:41 (4 years ago)

Author:

simonpj@…

Comment:

--

TypeDirectedNameResolution

@@ -7 +7 @@
 || Related      || [wiki:ExistingRecords] ||
 
-See email thread at [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723]
-
-Right at the end of the page is a straw poll about the proposal.
+See also
+ * email thread at [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723]
+ * The [http://haskell.org/haskellwiki/TypeDirectedNameResolution publicly-editable TDNR discussion page], and straw poll
 
 == Exploiting the power of the dot ==
@@ -100 +100 @@
   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 
@@ -122 +122 @@
  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)
@@ -205 +205 @@
 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:
 {{{
 data Map k v
@@ -253 +253 @@
 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"?
 
@@ -276 +276 @@
 `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.  
 
@@ -283 +283 @@
 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.
 
@@ -311 +311 @@
 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''