Hi everyone, I have two modules that share a common data type in their respective data structures: package Aaa where newtype Foo = Foo String data Bar = Bar { barFoo :: [Foo] } deriving (Show, Eq) ... package Bbb where newtype Foo = Foo String data Quux = Quux { quuxFoo :: [Foo] } deriving (Show, Eq) ... Both modules require the Foo newtype defined. However, in all other respects they are separate modules that can be used independently. Defining the newtype Foo twice, as above, throws a compilation error (ambigious reference). Importing one module inside another breaks independence. I've been including newtype Foo in a Common.hs module that is included in both, as I would in C or C++. This sort of thing can easily get more complicated as the program grows however. I was wondering if the Haskell community has a better solution to this that I've overlooked. Ian Knopke
What about making a third module that defines and exports Foo ?
David.
2013/4/29 Ian Knopke
Hi everyone,
I have two modules that share a common data type in their respective data structures:
package Aaa where
newtype Foo = Foo String
data Bar = Bar { barFoo :: [Foo] } deriving (Show, Eq) ...
package Bbb where
newtype Foo = Foo String
data Quux = Quux { quuxFoo :: [Foo] } deriving (Show, Eq) ...
Both modules require the Foo newtype defined. However, in all other respects they are separate modules that can be used independently.
Defining the newtype Foo twice, as above, throws a compilation error (ambigious reference). Importing one module inside another breaks independence. I've been including newtype Foo in a Common.hs module that is included in both, as I would in C or C++. This sort of thing can easily get more complicated as the program grows however.
I was wondering if the Haskell community has a better solution to this that I've overlooked.
Ian Knopke
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
I've been including newtype Foo in a Common.hs module that is included in both
Ah, you alredy did that, I didn't see it. Sorry for the noise.
2013/4/29 David Virebayre
What about making a third module that defines and exports Foo ?
David.
2013/4/29 Ian Knopke
Hi everyone,
I have two modules that share a common data type in their respective data structures:
package Aaa where
newtype Foo = Foo String
data Bar = Bar { barFoo :: [Foo] } deriving (Show, Eq) ...
package Bbb where
newtype Foo = Foo String
data Quux = Quux { quuxFoo :: [Foo] } deriving (Show, Eq) ...
Both modules require the Foo newtype defined. However, in all other respects they are separate modules that can be used independently.
Defining the newtype Foo twice, as above, throws a compilation error (ambigious reference). Importing one module inside another breaks independence. I've been including newtype Foo in a Common.hs module that is included in both, as I would in C or C++. This sort of thing can easily get more complicated as the program grows however.
I was wondering if the Haskell community has a better solution to this that I've overlooked.
Ian Knopke
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Hi, Ian, you can use qualified imports to manage that. Then you can write
module Test where
import qualified Aaa as QualifiedA ( Foo )
import Bbb ( Foo )
Below you can use barFoo by prepending QualifiedA e.g.
fooA = QualifiedA.Foo "Hi, I'm from A" fooB = Foo "I belong to B"
More information is available at http://www.haskell.org/haskellwiki/Import Regards, Nikita On 29/04/13 12:28, Ian Knopke wrote:
Hi everyone,
I have two modules that share a common data type in their respective data structures:
package Aaa where
newtype Foo = Foo String
data Bar = Bar { barFoo :: [Foo] } deriving (Show, Eq) ...
package Bbb where
newtype Foo = Foo String
data Quux = Quux { quuxFoo :: [Foo] } deriving (Show, Eq) ...
Both modules require the Foo newtype defined. However, in all other respects they are separate modules that can be used independently.
Defining the newtype Foo twice, as above, throws a compilation error (ambigious reference). Importing one module inside another breaks independence. I've been including newtype Foo in a Common.hs module that is included in both, as I would in C or C++. This sort of thing can easily get more complicated as the program grows however.
I was wondering if the Haskell community has a better solution to this that I've overlooked.
Ian Knopke
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
On Mon, Apr 29, 2013 at 11:28:03AM +0100, Ian Knopke wrote:
I've been including newtype Foo in a Common.hs module that is included in both, as I would in C or C++. This sort of thing can easily get more complicated as the program grows however.
That is exactly what I would do, and is a common practice. For example, you will often see a module named something like 'Foo.Bar.Types' which contains declarations of common types which are used in many other modules. I am not sure what you mean when you say that this can get complicated as the program grows. I have some fairly large packages using this technique and in practice I have not seen much complication. Can you give an example of the sort of complication you mean? -Brent
Common practice are the Common.hs, Types.hs or Internal.hs modules with the internally shared code of your package.
Just import them on modules Aaa and Bbb and reexport what is needed by the users of those modules so they can write only one import declaration.
Look at http://hackage.haskell.org/packages/archive/binary/0.7.0.1/doc/html/Data-Bin... and http://hackage.haskell.org/packages/archive/blaze-builder/0.3.1.1/doc/html/B... (the Builder type is in Blaze.ByteString.Builder.Internal.Types and is used everywhere).
On Apr 29, 2013, at 10:44 AM, Brent Yorgey
example, you will often see a module named something like 'Foo.Bar.Types' which contains declarations of common types which are used in many other modules.
participants (5)
-
Brent Yorgey -
David Virebayre -
Federico Mastellone -
Ian Knopke -
Nikita Danilenko