You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Andreas Voellmy <an...@gmail.com> on 2015/04/25 22:59:09 UTC

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

Re: Ambiguous exports in Haskell-generated code

Posted by Andreas Voellmy <an...@gmail.com>.
Actually, I just realized that the issue was fixed in 0.9.2 (I was using
0.9.1). Upgrading to 0.9.2 fixed the issue. I marked the JIRA issue as
resolved.

Andi

On Sun, Apr 26, 2015 at 10:19 AM, Andreas Voellmy <andreas.voellmy@gmail.com
> wrote:

> Sure, I'll give it a try. For now, I've created a JIRA issue for it
> https://issues.apache.org/jira/browse/THRIFT-3116.
>
> -Andi
>
> On Sun, Apr 26, 2015 at 6:24 AM, Jens Geyer <je...@hotmail.com> wrote:
>
>> 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: user@thrift.apache.org
>> 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
>>
>
>

Re: Ambiguous exports in Haskell-generated code

Posted by Andreas Voellmy <an...@gmail.com>.
Sure, I'll give it a try. For now, I've created a JIRA issue for it
https://issues.apache.org/jira/browse/THRIFT-3116.

-Andi

On Sun, Apr 26, 2015 at 6:24 AM, Jens Geyer <je...@hotmail.com> wrote:

> 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: user@thrift.apache.org
> 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
>

Re: Ambiguous exports in Haskell-generated code

Posted by Jens Geyer <je...@hotmail.com>.
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: user@thrift.apache.org
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