Hi Andi,
thanks for catching this. Mind to submit a patch?
http://thrift.apache.org/docs/HowToContribute
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Andreas Voellmy
Sent: Saturday, April 25, 2015 10:59 PM
To: [email protected]
Subject: Ambiguous exports in Haskell-generated code
It looks like the Thrift-generated Haskell exports functions in a way that
causes problems. For example, when I use thrift on the tutorial example,
and then I start up ghci and do
Prelude> :l Calculator_Client.hs
[1 of 8] Compiling Shared_Types ( Shared_Types.hs, interpreted )
[2 of 8] Compiling Tutorial_Types ( Tutorial_Types.hs, interpreted )
[3 of 8] Compiling SharedService_Iface ( SharedService_Iface.hs,
interpreted )
[4 of 8] Compiling SharedService ( SharedService.hs, interpreted )
[5 of 8] Compiling Calculator_Iface ( Calculator_Iface.hs, interpreted )
[6 of 8] Compiling Calculator ( Calculator.hs, interpreted )
[7 of 8] Compiling SharedService_Client ( SharedService_Client.hs,
interpreted )
[8 of 8] Compiling Calculator_Client ( Calculator_Client.hs, interpreted )
Calculator_Client.hs:15:45:
Ambiguous occurrence ‘zip’
It could refer to either ‘Calculator_Client.zip’,
defined at Calculator_Client.hs:112:1
or ‘Data.ByteString.Lazy.zip’,
imported from ‘Data.ByteString.Lazy’ at
Calculator_Client.hs:24:1-27
Failed, modules loaded: SharedService_Client, Shared_Types, Tutorial_Types,
Calculator, SharedService, Calculator_Iface, SharedService_Iface.
The problem is that zip (from the service definition) is also exported by
Data.ByteString.Lazy. One solution to this is to import all modules using
qualified imports.
-Andi
