Changes between Version 7 and Version 8 of TypeDirectedNameResolution


Ignore:
Timestamp:
Nov 17, 2009 6:00:41 PM (6 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''