Will, just doing "import Data.Integer" should not give you an error, but it
also will not import "toString" (or any other function) without a
namespace.

If your code looks like

import Data.Integer

x = toString y
>

then "toString" is not ambiguous. It could only possibly refer to
"Basics.toString."

The situation that I (and I think Pete) thought you were referring to is
when your code looks like

import Data.Integer exposing (..)
>
x = toString y
>

In this case, "toString" is ambiguous. But because it is ambiguous, this
code will not compile!

I am sorry if I am explaining things that you already know, but I don't
think it is clear from your OP exactly what the situation is that you are
talking about. Could you provide us some sample code that is giving you
unexpected results?

Thanks,
Nick



On Thu, Jul 21, 2016 at 12:48 AM, Will White <[email protected]> wrote:

> I certainly don't remember such an error. In elm repl I can do this
> without any problem:
>
> > import Data.Integer
>
> >
>
>
>
> On Wednesday, July 20, 2016 at 4:54:57 PM UTC+1, Peter Damoc wrote:
>>
>> Will,
>>
>> did you import elm-integer's toString and it did not give you an error
>> about the duplication?
>>
>> This sounds unexpected. Do you have a SSCCE showing this kind of problem?
>>
>>
>>
>>
>>
>> On Wed, Jul 20, 2016 at 5:12 PM, Will White <[email protected]> wrote:
>>
>>> Just to be clear, in 1. I did `toString Integer`, expecting that to
>>> call elm-integer's toString, not Basic.toString.
>>> In the first bullet point, I meant to say "...even though `toString
>>> Integer` is valid...".
>>>
>>>
>>> On Wednesday, July 20, 2016 at 3:04:23 PM UTC+1, Will White wrote:
>>>>
>>>> Coming from
>>>> https://github.com/elm-lang/error-message-catalog/issues/135, I'd like
>>>> to know what you think we could do about ambiguous uses of e.g. `toString`.
>>>> For instance:
>>>>
>>>>
>>>>    1. I was using elm-integer, which has its own `toString` function
>>>>    for its massive integers, and I called it on an elm-integer Integer.
>>>>    2. My code *actually* called `Basics.toString` on the Integer, so
>>>>    the result was not as expected. Luckily I caught it.
>>>>
>>>> I can think of two ways to handle there being more than one toString
>>>> around:
>>>>
>>>>
>>>>    - Warn the developer that the use of `toString` is ambiguous, even
>>>>    though `Basics.toString Integer` *is* valid (Basics.toString
>>>>    changes *any* type to a String). Namespacing the toString would
>>>>    make the warning go away.
>>>>    - Call the toString that's in the same module as the type of the
>>>>    argument is in, i.e. the toString that's in the same module as Integer.
>>>>
>>>> I'm sure this will affect other functions as well as `toString`.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to