What to do about ambiguous `toString`?

[Will White]

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`.

[Will White]

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...".

[Peter Damoc]

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?

--
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 elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Nick H]

I would love a compiler warning for this. It already warns about unused imports. Warning about naming collisions would be in the same spirit of encouraging code quality.

Even with the warning, this is a good reason to use unqualified imports sparingly. If the package name is long or I use it frequently, I might shorten the name (for example "import Data.Integer as Int"). But I almost never import functions without a namespace.

The Elm documentation warns that unqualified imports are a bad idea, but this warning is hidden in the API Design Guidelines

A function called State.runState is redundant and silly. More importantly, it encourages people to use import State exposing (..) which does not scale well. In files with many so-called "unqualified" dependencies, it is essentially impossible to figure out where functions are coming from. This can make large code bases impossible to understand, especially if custom infix operators are used as well. Repeating the module name actively encourages this kind of unreadable code.

With a name like State.run the user is encouraged to disambiguate functions with namespacing, leading to a codebase that will be clearer to people reading the project for the first time.

 

[Peter Damoc]

Elm warns about name collisions. This is why I was asking Will about the context. 

I sometimes don't care about name collisions, I import multiple modules unqualified and just disambiguate at the top of the file. 

It is wrong, stupid and it should not be done but sometimes I do that :) . 
I know it is something I can fix after I'm done with the functionality. 

[Nick H]

Huh, you are right. Well, now I am confused too.

I must have been thinking of the situation where you define a function that reuses the name of an imported function.

[Max Goldstein]

I think I opened an issue for this, search for author:mgold and you should find it. Definitely add missing relevant examples!

[Will White]

I certainly don't remember such an error. In elm repl I can do this without any problem:

> import Data.Integer

[Will White]

Max, I can't find this issue. There's https://github.com/elm-lang/error-message-catalog/issues/80 but it's not quite the same.

[Max Goldstein]

Here: https://github.com/elm-lang/error-message-catalog/issues/59

Sorry for the wild goose chase.

[Nick H]

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

[Will White]

Gahhh! I must have been doing just `import Data.Integer` without `exposing` because: 

> import Data.Integer exposing (..)

> x = toString (Data.Integer.fromInt 1)

-- NAMING ERROR ---------------------------------------------- repl-temp-000.elm

This usage of variable `toString` is ambiguous.

6| x = toString (Data.Integer.fromInt 1)

       ^^^^^^^^

Maybe you want one of the following?

    Basics.toString

    Data.Integer.toString

Really sorry everyone!

[Will White]

I've been thinking about this since... what's the purpose of `import` if always using `import exposing` means I wouldn't have gotten into this mess?