text: . This creates a potential ambiguity: did you mean
  <module-name>.f or
  <record-name>.f.
  Record could be the name of a type or of a module.
  There are 2 cases to consider: 1) inside module M naming a record M, and also importing both that module and record 2) importing 2 different modules, M1 and M2, where M2 defines a record named M1.
  The module/record ambiguity is dealt with in Frege by preferring modules and requiring a module prefix for the record if there is ambiguity. So for 1) you need M.M.field. For 2) you need M2.M1.field.
  We could instead prefer a record rather than a module - this would normally be the desired behavior, but then we must figure out how to still be able to access the module. This is particularly the case for modules not marked as qualified - generally all modules are under a verbose namespace and the Module.identifier syntax is only used if the module is first qualified.
  Getting rid of the Verbosity with the dot operator
  We have name-spaces, but it is hard to see how this is better than the current practice of adding prefixes to record fields:
  data Record = Record { recordA :: String }
  Verbosity is solved in Frege and DDC by using the dot syntax concept. In
  data Record = Record {a::String};r = Record "A"; r.a The final
  r.a resolves to
  Record.a r.
  This is the TDNR syntax concept. See 'Simple Type Resolution' for how we resolve the type of this code. Also see 'Details on the dot' for a lengthy discussion of the dot.and knows that
  x::R
  - In code that lives itself in the namespace
  R, here even an unqualified
  fwill resolve to
  R.f(unless, of course, if there is a local binding for
  f)
  Increased need for type annotation
  This is the only real downside of this proposal - most downsides discussed here are inherent to any recordsof data type
  Tis
  T.{x=}
  - the function that sets field x in a
  Tto
  42is
  T.{x=42}
  - If
  a::Tthen
  a.{x=}and
  a.{x=42}are equivalent to
  T.{x=} a definitely.a
  Details on the dot
  This proposal requires the current Haskell function composition dot operator to have spaces on both sides. No spaces around the dot are reserved for name-spacing: this use and the current module namespace use. No space to the right would be partial application (see TDNR. The dot operator should bind as tightly as possible.
  Partial code
  Identifying the difference between a name-space dot and function composition
  Given the dot's expanded use here, plus its common use in custom operators, it is possible to end up with dot-heavy code.
  quux (y . (foo>.< bar).baz (f . g)) moo
  It's not that easy to distinguish from
  quux (y . (foo>.< bar) . baz (f . g)) moo
  What then is the future of the dot if this proposal is accepted? The community needs to consider ways to reduce the dot:
  1)
  @<.
  Downside:
  Extending data name-spacing - we are simply asking too much of the dot right now. However, it is consistent to extend the function name-spaced to a record data type concept to any data type (as it is in Frege), and use dot syntax for that. The dot (without spaces) then .
  Both Frege and the DDC thesis take this approach., most library users will likely find it more convenient to define functions at the top level of modules rather than to always lift them into data structure name-spaces with typeclasses.