Changes between Version 7 and Version 8 of TypeDirectedNameResolution


Ignore:
Timestamp:
Nov 17, 2009 6:00:41 PM (5 years ago)
Author:
simonpj@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeDirectedNameResolution

    v7 v8  
    77|| Related      || [wiki:ExistingRecords] || 
    88 
    9 See email thread at [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723] 
    10  
    11 Right at the end of the page is a straw poll about the proposal. 
     9See also 
     10 * email thread at [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723] 
     11 * The [http://haskell.org/haskellwiki/TypeDirectedNameResolution publicly-editable TDNR discussion page], and straw poll 
    1212 
    1313== Exploiting the power of the dot == 
     
    100100  For example, `a`, `a.f` and `a.f.g` are atoms. 
    101101 
    102  * The dynamic semantcs of `a.f` is simply reverse application `(f a)`. 
     102 * The dynamic semantics of `a.f` is simply reverse application `(f a)`. 
    103103 
    104104 * Unlike normal unqualified variable occurrences, it is legal for there to be many `f`'s  
     
    122122 and the standard notation for that is "r.f". 
    123123 * TDNR is doing the same job as Haskell's existing qualified names,  
    124  so it makes sense to use the sane notatoin. 
     124 so it makes sense to use the sane notation. 
    125125 
    126126Of course, there is a problem: Haskell already uses dot for (a) 
     
    205205can be any old function whose type looks like "''t1 -> t2''".  So the 
    206206first argument of a curried function is special.  For example, 
    207 consider a finite map module with signaturs like this: 
     207consider a finite map module with signatures like this: 
    208208{{{ 
    209209data Map k v 
     
    253253problem is that you could then ''only'' refer to `x` and `y` using 
    254254TDNR, and I rather dislike that; I would prefer TDNR to be a convenient 
    255 abbrevation for something one could write more verbosely.  If you 
     255abbreviation for something one could write more verbosely.  If you 
    256256like, what is their "original name"? 
    257257 
     
    276276`get`?  Arguably yes: if we allow both S and T to be defined in the 
    277277same module, even though they have the same field names, 
    278 it'd make sene to allow their accessor functions to 
     278it'd make sense to allow their accessor functions to 
    279279defined too.   
    280280 
     
    283283TDNR.  This latter is different to record fields (whose types are 
    284284inherently suitable).  So I propose to allow a module to contain 
    285 muliple types with the same field; but not muliple functions with the 
     285muliple types with the same field; but not multiple functions with the 
    286286same name. 
    287287 
     
    311311What about `(.x.y)`?  Does that expand to `(\f -> f.x.y)`? 
    312312 
    313 = Straw poll = 
    314  
    315 It's hard to gauge how much people like proposals like this, so let's try the experiment of collecting votes here: 
    316  
    317 Names of people who would positively like to see TDNR happen (say briefly why) 
    318  * Simon PJ (I wrote the proposal) 
    319  
    320 Names of people who think that on balance it's a bad idea 
    321  * fill in here 
    322  
    323 == Other comments == 
    324  
    325 ''Add your own comments here''