Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, "submodules". I know that this introduces a few
corner cases that need to be thought through -- what happens with overlapping
declarations, for example. But I tend to think the path here is relatively
straightforward and obvious, and the added expressive power should make
namespacing issues much more tractable. Like the type-level strings proposal,
this isn't about implementing records as such -- rather, it's about generally
extending the expressive power of the language so that record systems--among
other things--are easier to write.
I'm agnostic about nested modules. In principle they would be a good thing.
However, for the application to records in particular, I'm not sure people
would relish saying this
module M where
module T where
data T = MkT { x,y :: Int }
module S where
data S = MkS { x,y : Int }
The trouble is that, as ever, it is easier to say "add nested modules" than it
is to say what that means. For example, if I say
import qualified M
(where M is defined as above), are the data types called M.T, M.S, or M.T.T and
M.T.T? What if I import unqualified?
Without a design it's hard to debate the pros and cons of different approaches
to the record question. If anyone is seriously advocating nested modules, the
first step is to work out a concrete design, in detail.
Simon
From: Gershom Bazerman [mailto:gersh...@gmail.com]
Sent: 31 December 2011 19:12
To: Simon Peyton-Jones
Cc: Greg Weber; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either, perhaps it isn't *that* important to anyone. That said, it clearly is
*somewhat* important to a lot of people, so doing nothing isn't very
satisfactory either.
Usually I feel I know how to move forward, but here I don't.
Simon
It seems to me that there's only one essential missing language feature, which
is appropriately-kinded type-level strings (and, ideally, the ability to
reflect these strings back down to the value level). Given that, template
haskell, and the HList bag of tricks, I'm confident that a fair number of
elegant records packages can be crafted. Based on that experience, we can then
decide what syntactic sugar would be useful to elide the TH layer altogether.
Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, "submodules". I know that this introduces a few
corner cases that need to be thought through -- what happens with overlapping
declarations, for example. But I tend to think the path here is relatively
straightforward and obvious, and the added expressive power should make
namespacing issues much more tractable. Like the type-level strings proposal,
this isn't about implementing records as such -- rather, it's about generally
extending the expressive power of the language so that record systems--among
other things--are easier to write.
Cheers,
Gershom
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
