darcs patch: removed use of RecordWildCards, which is buggy in ghc ...
I'd prefer for this misfeature not to be used even if it *weren't*
buggy! What a terrible idea, to introduce a syntactic sugar that
shadows an existing binding with a totally different value of a
different type, in such a way that you can only discover what has been
done by searching some different file! If you did this by hand,
compiling with -Werr -Wall would lead to a compile error---and rightly
so.
David
Wed Sep 9 06:46:53 EDT 2009 David Roundy
Actually, field names and values are in different namespaces. It just happens that when declaring a field the compiler declares both a field name and a value (a selector) that are textually the same, but otherwise unrelated. That said, the patch is still a good idea. so applied. thanks! John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
But field names are also function names, which are values, and live in
the same namespace. That's what makes it so confusing (to me). If
you fail to see those two little . then you end up reading the code
completely wrong. It remains syntactically valid, but fails to type
check. But humans are very bad (or perhaps I should say *I* am very
bad) at type inference, so it can take a very long time to figure out
where the error lies.
David
On Wed, Sep 9, 2009 at 7:01 PM, John Meacham
Actually, field names and values are in different namespaces. It just happens that when declaring a field the compiler declares both a field name and a value (a selector) that are textually the same, but otherwise unrelated.
That said, the patch is still a good idea. so applied. thanks!
John
On Wed, Sep 09, 2009 at 07:08:25PM -0400, David Roundy wrote:
But field names are also function names, which are values, and live in the same namespace. That's what makes it so confusing (to me). If you fail to see those two little . then you end up reading the code completely wrong. It remains syntactically valid, but fails to type check. But humans are very bad (or perhaps I should say *I* am very bad) at type inference, so it can take a very long time to figure out where the error lies.
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. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Wed, Sep 9, 2009 at 7:34 PM, John Meacham
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
participants (3)
-
David Roundy -
David Roundy -
John Meacham