[jhc] darcs patch: removed use of RecordWildCards, which is buggy in ghc ...

[David Roundy]

On Wed, Sep 9, 2009 at 7:34 PM, John Meacham <john at repetae.net> wrote:
> The fact that there happens to be a field name and a function name that
> are textually the same does not actually cause them to be related. For
> instance, the following is valid:
>
> data Foo = Foo { foo :: Int }
>    deriving(Show)
>
> main = do
>    let foo = 4
>    print Foo { foo = foo }
>
> the name to the left of the '=' sign is looked up in the field
> namespace, the value on the right is looked up in the value namespace,
> which are unrelated. shadowing in one doesn't affect the other.
>
> a decaration like the data Foo above declares both a value 'foo' and a
> field selector 'foo'. It is annoying that the haskell module system
> doesn't allow fine control of what you are actually importing and
> exporting, forcing things like having to have distinct type and class
> names, even though they are in distinct namespaces and shouldn't
> collide.

Right, it's the collision with the value 'foo' that bothers me.  I
understand that the field selector is in a distinct namespace, but any
collision is bad for readability, so far as I'm concerned.  e.g. your
let foo = 4 code above would be a bad idea, because it forces the
reader to look twice to figure out what "foo" is.  But it's nowhere
near as bad as the record wild card syntax, because in this example
(and any other Haskell syntax I'm familiar with), a grep for 'foo'
through a particular function will suffice to show us whether it's the
global 'foo' value or a local 'foo' value.
-- 
David Roundy