Given

            data T = T { x,y::Int }
            data S = S { x,y::Int }

            f :: S -> T
            f s = T { x = S.y s, y = S.x s }

Within the braces, the x and y on the LHS of the "="s are clearly field
labels of the type being constructed and so shouldn't need
qualification, and as above the x and y functions of S need to be
qualified, as you write.  My suggestion is that an unqualified x or y on
the rhs could be implicitly taken to be the corresponding function of T.

ie in
             g :: S -> T -> T
             g s t = t{ x = S.y s, y = x t }
would mean
             g s t = t{ x = S.y s, y = T.x t }

I think any confusion in the programmer's mind about which "x" is
intended would lead to a type error, so the improved readability seems
worthwhile.

Robin

-----Original Message-----
From: Simon Peyton-Jones
To: Garner, Robin; haskell@haskell.org
Sent: 13/09/02 17:32
Subject: RE: Labelled field restrictions

...

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.