It being rare means you're less likely to spot it when it happens. Do you namespace all your Html, for example?
On Thursday, August 18, 2016 at 11:39:25 PM UTC+1, Joey Eremondi wrote: > > @Will White: this case is excedingly rare. For example, it's not possible > to write "toString : a -> String" in Pure Elm. It needs Native code to do > so. There are theorems that say that any function of the type (a -> T) for > some concrete type T have to ignore their argument. The key is that > toString isn't polymorphic in its return type. > > There won't be (a -> JSON) or (a -> Dict Int String) or (a -> Html Msg) > functions floating around. String is a special case, where we break the > rules for practical debugging. > > So yes, it happens any time that there's a function polymorphic in its > argument *and not in its return type*, but this is basically only with > toString. It's not like every module exports its own version of (\ x y -> > x). > > The case you describe is possible, and still awkward even if the compiler > does catch your mistake. But the solution is *just don't import > Module1WithToX > exposing (..)*. Do Module1WithToX.toX. Your code will be clearer, and it > will not be ambiguous which one you mean. > > > On Thu, Aug 18, 2016 at 3:26 PM, Will White <[email protected] > <javascript:>> wrote: > >> 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 <[email protected]> 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 < >>>>> [email protected]>: >>>>> >>>>> 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 <[email protected]>: >>>>> >>>>> 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 <[email protected]>: >>>>>> >>>>>> 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 <[email protected]> >>>>>> 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 < >>>>>>>> [email protected]> 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 <[email protected]>: >>>>>>>>> >>>>>>>>>> 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 <[email protected]>: >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected] >>>>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> 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 [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. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> 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. >>>>>> >>>>>> -- >>>>> 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. >>>> >>> >>> -- >> 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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
