Without import exposing (..) by default, it'll be the same problem if there
are two functions with the same name from two modules, and either they both
have the same type signature, or one of them is polymorphic in its argument.
> import Module1WithToX exposing (toX)
> import Module2WithToX
> toX "r"
"rr" : String
> import Module1WithToX exposing (..)
> import Module2WithToX exposing (..)
> toX "r"
-- NAMING ERROR ---------------------------------------------- repl-temp-
000.elm
This usage of variable `toX` is ambiguous.
5| toX "r"
^^^
Maybe you want one of the following?
Module1WithToX.toX
Module2WithToX.toX
On Thursday, August 18, 2016 at 10:23:57 PM UTC+1, Joey Eremondi wrote:
>
> Okay, so I think this is somewhat of a special case. The problems you are
> running into come because toString is provided by Basics, so you expected
> your import to shadow it, but it did not.
>
> This is a bit of a tricky scenario:
> * The typechecker can't help us, because Basics.toString has type (a
> -> String) i.e. polymorphic in its argument, so it will always typecheck
> * The whole point of Basics.toString is to be a quick and dirty
> debugging tool, so needing to import it is a hassle
>
> When we use Foo.map, generally the typechecker will tell us if we used
> List.map when we wanted Maybe.map. So we shouldn't use polymorphic values
> with the same name when we don't have to.
>
> Solutions:
> * Rename Basics.toString, maybe to Basics.showAnything, or something
> similar
> * Move Basics.toString to Debug.toString, and import Debug qualified by
> default.
>
> Non-solutions:
> * Import everything unqualified by default, shadowing Basics
>
>
>
> On Thu, Aug 18, 2016 at 2:15 PM, Will White <will.n...@gmail.com
> <javascript:>> wrote:
>
>> In the first snippet, I was erroneously expecting toString to call
>> toString from ModuleWithToString, possibly because I'd just been looking at
>> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>>
>> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> Or maybe I'm still misunderstanding what your exact problem is in the
>>> absence of "exposing (..)". Maybe you can expand on the problem description
>>> from your first message in this thread?
>>>
>>> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer <janis.voi...@gmail.com
>>> >:
>>>
>>> You won't be able to forget one if "exposing (..)" is eliminated from
>>> the language, as is proposed in the issue I linked to.
>>>
>>> You'd then either have to qualify or add the entities explicitly in
>>> "exposing (concrete entities)". Problem solved, because in both cases a
>>> reader of the code does not need to wonder too much where any given name
>>> comes from.
>>>
>>> Am 18.08.2016 um 22:19 schrieb Will White <will.n...@gmail.com>:
>>>
>>> Then I'll always namespace them. If I forget one though...
>>>
>>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer
>>> wrote:
>>>>
>>>> More importantly, maybe, you will have to *remember* to use each
>>>> imported function at least once in qualified form in each module, or you
>>>> will end up in the situation Nick described, where in six months you don't
>>>> know (and other readers of your code do not even know the next day after
>>>> you wrote the code) where reticulateSplines comes from.
>>>>
>>>> Am 18.08.2016 um 20:03 schrieb Nick H <falling...@gmail.com>:
>>>>
>>>> Is that a good idea? It seems like occasionally, but not always, using
>>>> the namespace would make your code less readable than not doing it at all.
>>>>
>>>>
>>>> On Thu, Aug 18, 2016 at 9:37 AM, Will White <will.n...@gmail.com>
>>>> wrote:
>>>>
>>>>> I can still namespace functions with import exposing (..).
>>>>>
>>>>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>>>>>
>>>>>> If you prefer not having to remember things, then you should use
>>>>>> qualified imports.
>>>>>>
>>>>>> Stripping the namespace off of all your imported functions means that
>>>>>> your code no longer tells you where these functions come from. You will
>>>>>> have to remember this information yourself. This doesn't seem like much
>>>>>> of
>>>>>> a mental burden at the moment, but it will likely become much more
>>>>>> burdensome in 6 months when you are reading through your code again
>>>>>> (e.g.
>>>>>> "Now, which of these 10 modules did that 'reticulateSplines' function
>>>>>> come
>>>>>> from?") And if you never run into that annoyance, I guarantee that every
>>>>>> other person who reads your code will.
>>>>>>
>>>>>> What's more, APIs that follow the design guidelines
>>>>>> <http://package.elm-lang.org/help/design-guidelines#naming> are
>>>>>> going to make your life even harder, because the functions will have
>>>>>> names
>>>>>> designed to work with a qualifier. Look at your own example. If
>>>>>> "toString"
>>>>>> only works on one type, then it is a terribly undescriptive name. But if
>>>>>> the module is named "Foo" and the type defined in that module is named
>>>>>> "Foo", then "Foo.toString" is not a terrible name.
>>>>>>
>>>>>> From the 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. A great example from the
>>>>>>> standard library is Bitwise.and
>>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
>>>>>> janis.voi...@gmail.com> wrote:
>>>>>>
>>>>>>> I can’t search for the thread right now, but I’m sure you can find
>>>>>>> it yourself via the archive. In any case, one aspect of it (but I think
>>>>>>> there were more) was this:
>>>>>>> https://github.com/elm-lang/elm-make/issues/61
>>>>>>>
>>>>>>>
>>>>>>> 2016-08-18 17:08 GMT+02:00 Will White <will.n...@gmail.com>:
>>>>>>>
>>>>>>>> What unexpected results? The compiler has your back if two
>>>>>>>> unqualified functions have the same name.
>>>>>>>>
>>>>>>>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> That's not an answer to my question I understand as a problem
>>>>>>>>> description.
>>>>>>>>>
>>>>>>>>> Also, there have been earlier threads here that have discussed
>>>>>>>>> what can go wrong if you unwittingly import with exposing everything.
>>>>>>>>> So,
>>>>>>>>> where not remembering that one of those imports brought a certain
>>>>>>>>> function
>>>>>>>>> name into scope, lead to unexpected results. If your concern is
>>>>>>>>> valid,
>>>>>>>>> theirs is at least as much.
>>>>>>>>>
>>>>>>>>> Am 18.08.2016 um 17:48 schrieb Will White <will.n...@gmail.com>:
>>>>>>>>>
>>>>>>>>> You have to remember to qualify.
>>>>>>>>>
>>>>>>>>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis
>>>>>>>>> Voigtländer wrote:
>>>>>>>>>>
>>>>>>>>>> In what ways are qualified imports at odds with safe code?
>>>>>>>>>>
>>>>>>>>>> I think the opposite is the case: unqualified imports lead to
>>>>>>>>>> less code safety.
>>>>>>>>>>
>>>>>>>>>> Am 18.08.2016 um 17:37 schrieb Will White <will.n...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>> I prefer safe code to qualified imports.
>>>>>>>>>>
>>>>>>>>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> "Qualified imports are preferred."
>>>>>>>>>>>
>>>>>>>>>>> http://elm-lang.org/docs/syntax#modules
>>>>>>>>>>>
>>>>>>>>>>> I try to avoid as much as possible importing everything from a
>>>>>>>>>>> module.
>>>>>>>>>>> If I would have IDE support for automatic imports I would never
>>>>>>>>>>> do a import Module exposing (..).
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> --
>>>>> 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.
>>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>> --
>>> 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.
>>>
>>> --
>> 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 <javascript:>.
>> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
