Records in Haskell - namespacing for fields

AntC anthony_clayden at
Wed Feb 1 07:52:24 CET 2012

John Lask <jvlask <at>> writes:

> On 1/02/2012 12:26 AM, AntC wrote:
> >
> > No! no! no! For records _don't_ put records in nested/sub-modules, and 
> > require them in separate modules (as currently). Here's how ...
> >
> namespace management and record systems are intimately related, but as 
> you assert distinct issues.
> taking your example of Customer_id, I expressly want to be able to 
> define in the same syntactic module (file). Two records with a field 
> with exactly the same name at two different types, say Customer_id :: 
> Int and Customer_id :: String. As I understand it, your proposal
> would not enable this.

John, you can't do this now. You can't even define in the same module two 
records with the same name with the _same_ type.

[I'd better check first why you've put Customer_id with upper case, that's a 
type, not a field. Are you sure what you're talking about?]

I'd certainly dispute that there's anything sensible in doing that (why? 
what's the use case?), and I guess my proposal is not making that easy, but it 
is possible (and in fact no more difficult than a 'fixed' type for a field).

You'd go:
      field customer_id :: r -> t  -- which is the same as no type spec at all
      data CustInt = CustInt { customer_id :: Int, ... }
      data CustString = CustString { customer_id :: String, ... }
It doesn't stop you also doing:
      data CustBool = CustBool { customer_id :: Bool, ... }

(I could contrive that the domain of customer_id is constrained to only Int or 
String, but why?)

> In reality these two different uses of the name Customer_id are 
> unrelated and distinct. Some would argue that therefore they should 
> rightly have distinct names, however that is moot, for the purpose of 
> this discussion lets take this as the objective.

No, I'm not going to take that as an objective. You'd have to provide a much 
better motivation for wanting to have two identical names in the same scope 
that are "unrelated and distinct".

I'd agree with the 'some' that you should use two different names. Or if this 
is an 'accidental' clash of names from developers working separately (this is 
my distant planet example), then the clash is not special for field names, and 
it's what the module system is for. Use My.customer_id and Their.customer_id.

> There are two roads to travel: Customer_id is one semantic entity (in 
> the sense of an overloaded field, disambiguated by the type system) or 
> Customer_id represents two distinct semantic entities disambiguated 
> syntactically. I for one favor the second approach as it matches my 
> intent, can I say, more faithfully.

I'm interested to know how you disambiguate syntactically distinct entities 
with identical names in the same scope.

> > [There may be other reasons for nested/sub-modules, but records ain't it.]
> as above, however, I believe the best approach is to explore both paths 
> and perhaps extend Haskell in both directions.

No, we can't afford to keep exploring multiple paths. What happens in fact is 
that it's extremely hard work, there's very few people who can actually 
implement it, they (frankly) are not very interested when there's so many 
other exciting possible developments. (Record systems don't count as exciting 
for programming language research: the ground is already well covered.) 
There's barely the resourcing to extend Haskell in just one way, and only 
providing the change is minimal.
Haskell 98's record system has been a wart since -- errm -- 1996.

> As in your example the particular construction of which suits, the 
> approach offered in your email better because it matches your intent 
> "more faithfully". It is this ability to match construction with intent 
> that is critical, which alludes to the notion of "the expressivity" of a 
> language.

Eh? This sounds like metaphysics.

More information about the Glasgow-haskell-users mailing list