Labelled field restrictions
Garner, Robin
Robin.Garner@crsrehab.gov.au
Fri, 13 Sep 2002 10:57:18 +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_01C25AC0.826CBC20
Content-Type: text/plain;
charset="iso-8859-1"
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_01C25AC0.826CBC20
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>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
</FONT></SPAN></DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>> data Rec
= Con { recField1 :: Type, recField2 :: Type ... }.</FONT></SPAN></DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>For example, given
the declarations</FONT></SPAN></DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>> data Type1 =
Con1 { field1 :: Type11, field2 :: Type12 }</FONT></SPAN></DIV>
<DIV><SPAN class=404432103-11092002><FONT face=Arial size=2>> data Type2 =
Con2 { field1 :: Type21, field3 :: Type22 }</FONT></SPAN></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=404432103-11092002>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></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=404432103-11092002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=404432103-11092002>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=404432103-11092002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=404432103-11092002>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></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=404432103-11092002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=404432103-11092002>Robin
Garner</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=404432103-11092002>A.N.U.</SPAN></FONT></DIV></FONT></DIV></BODY></HTML>
------_=_NextPart_001_01C25AC0.826CBC20--