A perfectly sensible idea. Main difficulty I see: it's not clear what T.x would mean if both type T and module T existed, though. Also if I have data T = T { x,y::Int } data S = S { x,y::Int } I might write f :: S -> T f s = T { x = S.y s, y = S.x s } So just because I'm inside a T construction doesn't mean that "x" or "y" are unambiguous. Simon -----Original Message----- From: Garner, Robin [mailto:Robin.Garner@crsrehab.gov.au] Sent: 13 September 2002 01:57 To: 'haskell@haskell.org' Subject: Labelled field restrictions One Haskell limitation that has always puzzled me (and other programmers I have spoken with) is why labels in labelled fields share the top level name space. In practice his means that you generally name fields with some combination of constructor or type name and a field name, eg
data Rec = Con { recField1 :: Type, recField2 :: Type ... }.
Is there a good reason why field labels couldn't be optionally qualified by the type name, and usable unqualified if they are unique in the current scope ? This would be consistent with the naming rules for other top-level names, just slightly more modular. In essence, the language would implicitly do what most programmers do already, but making life easier where possible. For example, given the declarations
data Type1 = Con1 { field1 :: Type11, field2 :: Type12 }
data Type2 = Con2 { field1 :: Type21, field3 :: Type22 }
field2 and field3 could be used unqualified, but field1 would need to be referred to as Type1.field1 or Type2.field1 to disambiguate them. Additionally, within a construction using field labels (ie an x{ field = value , ...} construct), labels local to the type of x could be used unqualified as selector functions (ie in value expressions). Field names on the left-hand side of bindings would not need qualification. Essentially, the scope of the type being constructed would take priority inside the {...}. Labels from other types that clash with named labels in the local type would need to be explicitly qualified by the type name. As far as I can see, this extension wouldn't break any existing programs, but would simply complicate symbol resolution in the compiler somewhat. Robin Garner A.N.U.