Changes between Version 9 and Version 10 of TypeDirectedNameResolution


Ignore:
Timestamp:
Nov 19, 2009 8:32:01 AM (6 years ago)
Author:
simonpj@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypeDirectedNameResolution

    v9 v10  
    286286same name.
    287287
     288== Qualified import ==
     289
     290Consider this
     291{{{
     292module R where
     293  data R = MkR { x,y::Int }
     294
     295module Foo where
     296  import qualified R   -- Note qualified
     297  f1, f2 :: R -> Int
     298  f1 r = R.y r
     299  f2 r = r.x
     300}}}
     301Here the `R.y` in `f1` is an ordinary qualified name.  But what should
     302`r.x` be allowed?  Remember plain `x` isn't in scope; only `R.x` is.  But
     303we don't want to have to force you to write `r.R.x`, even if we could parse
     304it!  Maybe TDNR should choose among in-scope x's regardless of whether they are
     305qualified or not.
     306
    288307== Record syntax ==
    289308
    290309TDNR can apply to record construction and pattern-matching, as indeed
    291 already happens in GHC with `-XDisambiguteRecordFields`.   However I
    292 propose ''not'' to apply it to record update, a construct that is already
    293 rather complicated to typecheck.  I do not want to make it worse.
     310already happens in GHC with `-XDisambiguteRecordFields`.  For example,
     311you could say
     312{{{
     313  a = R { x = 3 }
     314  f (R {x = xval}) = xval
     315}}}
     316even if there were many x's in scope.
     317
     318However I propose ''not'' to apply it to record update.  Specifically
     319I propose not to take the expression
     320{{{
     321  r { x=3 }
     322}}}
     323and try to figure out which of many in-scope x's you mean by looking at the type of 'r'.
     324That's be possible, but it gets complicated: what about `(f v) {x=3}`?  Record update
     325is already rather complicated to typecheck.  I do not want to make it worse.
    294326
    295327== Section-style selection ==