Dear Haskellers, Why can't field labels have the same name in different types? Here's some actual code on finite state automata I'm working on:
data BMC = BMC { node :: !Int, threshold :: !Float, edge0 :: BMC, edge1 :: BMC }
data BFSM = BFSM { bfsmnode :: !Int, bfsmstate :: Maybe Bool, bfsmoutput :: [Bool], bfsmedge0 :: BFSM, bfsmedge1 :: BFSM }
What I really want is to use the same field labels of node, edge0, and edge1 in the BFSM type, but I can't because otherwise I get the following in hugs: ERROR xxx - Repeated definition for selector "edge0" I'm not an expert on programming languages, but doesn't it seem that Haskell, as a strongly-typed language, should not have any problem distinguishing the field labels of different datatypes? Kim-Ee
G'day all. On Tue, Jan 07, 2003 at 10:01:38PM -0600, Kim-Ee Yeoh wrote:
Why can't field labels have the same name in different types?
Because it would generate two functions with the same name.
I'm not an expert on programming languages, but doesn't it seem that Haskell, as a strongly-typed language, should not have any problem distinguishing the field labels of different datatypes?
There are two possible ways to get around it. One is to allow function overloading. This is probably not desirable because it turns type checking into an NP-hard problem. The other is to make a record introduce a new namespace. We've discussed this previously, and I think the consensus was that it's a good idea in theory, but it was too incompatible with Haskell 98. Were there any other objections? I can't remember. Cheers, Andrew Bromage
On Wed, 8 Jan 2003, Andrew J Bromage wrote:
One is to allow function overloading. This is probably not desirable because it turns type checking into an NP-hard problem.
it already is much harder (even without static overloading) Helmut Seidl. : Haskell overloading is DEXPTIME-complete. Information Processing Letters 52(2), 57-60, 1994. http://www.informatik.uni-trier.de/~seidl/papers/type.ps and extensions make it worse (hence `ghc -fallow-undecidable-instances`) which doesn't stop them from being useful. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
--------------------It would be nice to be able to overload class-functions like classes: instance (+), (-) -> Vector where (+) v1 v2 = ... (-) v1 v2 = ... --------------------instead of overloading parts of a class... (because of runtime-errors!) instance Num Vector where (+) v1 v2 = ... (-) v1 v2 = ... (*) _ _ = undefined (/) _ _ = undefined --------------------or BETTER just to split classes: class HalfBody a => (Num a =>(+), (-)) where instance HalfBody Vector where (+) v1 v2 = ... (-) v1 v2 = ... --------------------instead of defining new operators... class HalfBody a where (+§) :: a -> a -> a (-§) :: a -> a -> a instance (Num a) => HalfBody a where (+§) = (+) (-§) = (-) instance HalfBody Vector where (+§) v1 v2 = ... (-§) v1 v2 = ... --------------------------------------------------------------------------------
One is to allow function overloading. This is probably not desirable because it turns type checking into an NP-hard problem.
--Just changed the syntax: ... --------------------or BETTER just to split classes: type class HalfBody a = (Num a => (+), (-)) instance HalfBody Vector where (+) v1 v2 = ... (-) v1 v2 = ... ... ----- Original Message ----- From: "Marc Ziegert" <coeus@gmx.de> To: <haskell@haskell.org> Sent: Wednesday, January 08, 2003 2:24 PM Subject: Re: Field labels must be globally unique?
--------------------It would be nice to be able to overload class-functions like classes:
instance (+), (-) -> Vector where (+) v1 v2 = ... (-) v1 v2 = ...
--------------------instead of overloading parts of a class... (because of runtime-errors!)
instance Num Vector where (+) v1 v2 = ... (-) v1 v2 = ... (*) _ _ = undefined (/) _ _ = undefined
--------------------or BETTER just to split classes:
class HalfBody a => (Num a =>(+), (-)) where
instance HalfBody Vector where (+) v1 v2 = ... (-) v1 v2 = ...
--------------------instead of defining new operators...
class HalfBody a where (+§) :: a -> a -> a (-§) :: a -> a -> a
instance (Num a) => HalfBody a where (+§) = (+) (-§) = (-)
instance HalfBody Vector where (+§) v1 v2 = ... (-§) v1 v2 = ...
--------------------------------------------------------------------------------
One is to allow function overloading. This is probably not desirable because it turns type checking into an NP-hard problem.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Wed, Jan 08, 2003 at 02:24:06PM +0100, Marc Ziegert wrote:
--------------------It would be nice to be able to overload class-functions like classes:
instance (+), (-) -> Vector where (+) v1 v2 = ... (-) v1 v2 = ... ...
You seem to be making a general complaint, but there's been extensive discussion about this particular instance. I agree with you that the numeric hierarchy is too coarsely grained right here; do a search on the archives for "numeric prelude" for an extensive discussion. Your proposals seem interesting, but seem hard to implement/make precise at first glance. Best, Dylan Thurston
This seems similar to my 'supertyping' proposal. The basic gist was that you can declare a superclass (which must have a subset of the members of the original class) after the declaration of the original class... my original message is here: http://repetae.net/john/computer/haskell/supertyping.txt John On Sun, Jan 12, 2003 at 09:37:25AM -0500, Dylan Thurston wrote:
On Wed, Jan 08, 2003 at 02:24:06PM +0100, Marc Ziegert wrote:
--------------------It would be nice to be able to overload class-functions like classes:
instance (+), (-) -> Vector where (+) v1 v2 = ... (-) v1 v2 = ... ...
You seem to be making a general complaint, but there's been extensive discussion about this particular instance. I agree with you that the numeric hierarchy is too coarsely grained right here; do a search on the archives for "numeric prelude" for an extensive discussion.
Your proposals seem interesting, but seem hard to implement/make precise at first glance.
Best, Dylan Thurston
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
a plausable workaround in haskell 98 is to use a typeclass like so class EdgyNodelike a where node :: a -> Int edge0 :: a -> a edge1 :: a -> a instance EdgyNodelike BFSM where node = bfsmnode edge0 = bfsmedge0 edge1 = bfsmedge1 instance EdgyNodelike BMC where node = bmcnode edge0 = bmcedge0 edge1 = bmcedge1 that will let you write code which works on anything with edges or nodes. John On Tue, Jan 07, 2003 at 10:01:38PM -0600, Kim-Ee Yeoh wrote:
Dear Haskellers,
Why can't field labels have the same name in different types?
Here's some actual code on finite state automata I'm working on:
data BMC = BMC { node :: !Int, threshold :: !Float, edge0 :: BMC, edge1 :: BMC }
data BFSM = BFSM { bfsmnode :: !Int, bfsmstate :: Maybe Bool, bfsmoutput :: [Bool], bfsmedge0 :: BFSM, bfsmedge1 :: BFSM }
What I really want is to use the same field labels of node, edge0, and edge1 in the BFSM type, but I can't because otherwise I get the following in hugs:
ERROR xxx - Repeated definition for selector "edge0"
I'm not an expert on programming languages, but doesn't it seem that Haskell, as a strongly-typed language, should not have any problem distinguishing the field labels of different datatypes?
Kim-Ee
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (6)
-
Andrew J Bromage -
Dylan Thurston -
Johannes Waldmann -
John Meacham -
Kim-Ee Yeoh -
Marc Ziegert