Labelled field restrictions
Simon Peyton-Jones
simonpj@microsoft.com
Fri, 13 Sep 2002 08:32:00 +0100
This is a multi-part message in MIME format.
--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C25AF7.A5CA6262"
------_=_NextPart_001_01C25AF7.A5CA6262
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
A perfectly sensible idea. =20
=20
Main difficulty I see: it's not clear what T.x would mean if both type T
and module T existed, though.
=20
Also if I have
=20
data T =3D T { x,y::Int }
data S =3D S { x,y::Int }
=20
I might write
=20
f :: S -> T
f s =3D T { x =3D S.y s, y =3D S.x s }
=20
So just because I'm inside a T construction doesn't mean that "x" or "y"
are unambiguous.=20
=20
=20
Simon
=20
-----Original Message-----
From: Garner, Robin [mailto:Robin.Garner@crsrehab.gov.au]=20
Sent: 13 September 2002 01:57
To: 'haskell@haskell.org'
Subject: Labelled field restrictions
=20
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=20
=20
> data Rec =3D Con { recField1 :: Type, recField2 :: Type ... }.
=20
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.
=20
For example, given the declarations
=20
> data Type1 =3D Con1 { field1 :: Type11, field2 :: Type12 }
> data Type2 =3D Con2 { field1 :: Type21, field3 :: Type22 }
=20
field2 and field3 could be used unqualified, but field1 would need to be
referred to as Type1.field1 or Type2.field1 to disambiguate them.
=20
Additionally, within a construction using field labels (ie an x{ field =
=3D
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.
=20
As far as I can see, this extension wouldn't break any existing
programs, but would simply complicate symbol resolution in the compiler
somewhat.
=20
Robin Garner
A.N.U.
------_=_NextPart_001_01C25AF7.A5CA6262
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body bgcolor=3Dwhite lang=3DEN-GB link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A perfectly sensible idea. =
</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Main difficulty I see: it’s =
not
clear what T.x would mean if both type T and module T existed, =
though.</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Also if I have</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial;color:navy'>data T =3D T { x,y::Int }</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  =
; data
S =3D S { x,y::Int }</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:navy'> </span></fo=
nt></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I might =
write</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  =
; </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>  =
; </span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>f :: S -> T</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> =
f
s =3D T { x =3D S.y s, y =3D S.x s }</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So just because I’m inside a =
T
construction doesn’t mean that “x” or “y” =
are
unambiguous. </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Simon</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>
<p class=3DMsoNormal><font size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Garner, Robin
[mailto:Robin.Garner@crsrehab.gov.au] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 13 September 2002 =
01:57<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
'haskell@haskell.org'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Labelled field
restrictions</span></font></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'> </span></font></p>
<div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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 </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>> data Rec =3D Con { recField1 :: Type, =
recField2 ::
Type ... }.</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For example, given the declarations</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>> data Type1 =3D Con1 { field1 :: Type11, field2 =
:: Type12
}</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>> data Type2 =3D Con2 { field1 :: Type21, field3 =
:: Type22
}</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>field2 and field3 could be used unqualified, but =
field1
would need to be referred to as Type1.field1 or Type2.field1 to =
disambiguate
them.</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Additionally, within a construction using field =
labels (ie
an x{ field =3D 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.</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As far as I can see, this extension wouldn't break =
any
existing programs, but would simply complicate symbol resolution in the
compiler somewhat.</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 face=3DArial><span =
style=3D'font-size:12.0pt;
font-family:Arial'> </span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Robin Garner</span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>A.N.U.</span></font></p>
</div>
</div>
</div>
</div>
</body>
</html>
------_=_NextPart_001_01C25AF7.A5CA6262--
--------------InterScan_NT_MIME_Boundary--