FW: Labelled field restrictions
Garner, Robin
Robin.Garner@crsrehab.gov.au
Sat, 14 Sep 2002 04:40:15 +1000
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C25B55.00126AF0
Content-Type: text/plain;
charset="iso-8859-1"
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.
------_=_NextPart_001_01C25B55.00126AF0
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>FW: Labelled field restrictions</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Given</FONT>
</P>
<P><FONT SIZE=2> data T = T { x,y::Int }</FONT>
<BR><FONT SIZE=2> data S = S { x,y::Int }</FONT>
</P>
<P><FONT SIZE=2> f :: S -> T</FONT>
<BR><FONT SIZE=2> f s = T { x = S.y s, y = S.x s }</FONT>
</P>
<P><FONT SIZE=2>Within the braces, the x and y on the LHS of the "="s are clearly field</FONT>
<BR><FONT SIZE=2>labels of the type being constructed and so shouldn't need</FONT>
<BR><FONT SIZE=2>qualification, and as above the x and y functions of S need to be</FONT>
<BR><FONT SIZE=2>qualified, as you write. My suggestion is that an unqualified x or y on</FONT>
<BR><FONT SIZE=2>the rhs could be implicitly taken to be the corresponding function of T.</FONT>
</P>
<P><FONT SIZE=2>ie in</FONT>
<BR><FONT SIZE=2> g :: S -> T -> T</FONT>
<BR><FONT SIZE=2> g s t = t{ x = S.y s, y = x t }</FONT>
<BR><FONT SIZE=2>would mean</FONT>
<BR><FONT SIZE=2> g s t = t{ x = S.y s, y = T.x t }</FONT>
</P>
<P><FONT SIZE=2>I think any confusion in the programmer's mind about which "x" is</FONT>
<BR><FONT SIZE=2>intended would lead to a type error, so the improved readability seems</FONT>
<BR><FONT SIZE=2>worthwhile.</FONT>
</P>
<P><FONT SIZE=2>Robin</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Simon Peyton-Jones</FONT>
<BR><FONT SIZE=2>To: Garner, Robin; haskell@haskell.org</FONT>
<BR><FONT SIZE=2>Sent: 13/09/02 17:32</FONT>
<BR><FONT SIZE=2>Subject: RE: Labelled field restrictions</FONT>
</P>
<P><FONT SIZE=2>...</FONT>
</P>
<P><FONT SIZE=2>Also if I have</FONT>
</P>
<P><FONT SIZE=2> data T = T { x,y::Int }</FONT>
<BR><FONT SIZE=2> data S = S { x,y::Int }</FONT>
</P>
<P><FONT SIZE=2>I might write</FONT>
<BR><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2> f :: S -> T</FONT>
<BR><FONT SIZE=2> f s = T { x = S.y s, y = S.x s }</FONT>
</P>
<P><FONT SIZE=2>So just because I'm inside a T construction doesn't mean that "x" or "y"</FONT>
<BR><FONT SIZE=2>are unambiguous. </FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>Simon</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Garner, Robin [<A HREF="mailto:Robin.Garner@crsrehab.gov.au">mailto:Robin.Garner@crsrehab.gov.au</A>] </FONT>
<BR><FONT SIZE=2>Sent: 13 September 2002 01:57</FONT>
<BR><FONT SIZE=2>To: 'haskell@haskell.org'</FONT>
<BR><FONT SIZE=2>Subject: Labelled field restrictions</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>One Haskell limitation that has always puzzled me (and other programmers</FONT>
<BR><FONT SIZE=2>I have spoken with) is why labels in labelled fields share the top level</FONT>
<BR><FONT SIZE=2>name space. In practice his means that you generally name fields with</FONT>
<BR><FONT SIZE=2>some combination of constructor or type name and a field name, eg </FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>> data Rec = Con { recField1 :: Type, recField2 :: Type ... }.</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>Is there a good reason why field labels couldn't be optionally qualified</FONT>
<BR><FONT SIZE=2>by the type name, and usable unqualified if they are unique in the</FONT>
<BR><FONT SIZE=2>current scope ? This would be consistent with the naming rules for</FONT>
<BR><FONT SIZE=2>other top-level names, just slightly more modular. In essence, the</FONT>
<BR><FONT SIZE=2>language would implicitly do what most programmers do already, but</FONT>
<BR><FONT SIZE=2>making life easier where possible.</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>For example, given the declarations</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>> data Type1 = Con1 { field1 :: Type11, field2 :: Type12 }</FONT>
</P>
<P><FONT SIZE=2>> data Type2 = Con2 { field1 :: Type21, field3 :: Type22 }</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>field2 and field3 could be used unqualified, but field1 would need to be</FONT>
<BR><FONT SIZE=2>referred to as Type1.field1 or Type2.field1 to disambiguate them.</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>Additionally, within a construction using field labels (ie an x{ field =</FONT>
<BR><FONT SIZE=2>value , ...} construct), labels local to the type of x could be used</FONT>
<BR><FONT SIZE=2>unqualified as selector functions (ie in value expressions). Field</FONT>
<BR><FONT SIZE=2>names on the left-hand side of bindings would not need qualification.</FONT>
<BR><FONT SIZE=2>Essentially, the scope of the type being constructed would take priority</FONT>
<BR><FONT SIZE=2>inside the {...}. Labels from other types that clash with named labels</FONT>
<BR><FONT SIZE=2>in the local type would need to be explicitly qualified by the type</FONT>
<BR><FONT SIZE=2>name.</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>As far as I can see, this extension wouldn't break any existing</FONT>
<BR><FONT SIZE=2>programs, but would simply complicate symbol resolution in the compiler</FONT>
<BR><FONT SIZE=2>somewhat.</FONT>
</P>
<P><FONT SIZE=2> </FONT>
</P>
<P><FONT SIZE=2>Robin Garner</FONT>
</P>
<P><FONT SIZE=2>A.N.U.</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C25B55.00126AF0--