On 2008 Aug 31, at 14:58, Daniel Fischer wrote:

Am Sonntag, 31. August 2008 20:21 schrieb Ryan Ingram:

...

Do you see it? All those "M." just seem dirty to me, especially because the compiler should be able to deduce them from the types of the arguments.

Another Con is that the compiler can catch fewer programming errors that way.

If omitting the qualifier doesn't cause this already then I don't think it will be much of a problem (either it won't find what you're looking for or it will be ambiguous). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Sun, Aug 31, 2008 at 2:10 PM, Claus Reinke wrote:

Indeed. Too much overloading can be a lot of trouble.

You can do adhoc overloading already:

{-# LANGUAGE FlexibleInstances #-}

class Adhoc a where adhoc :: a

instance Adhoc ((a->b)->([a]->[b])) where adhoc = map instance Adhoc (Maybe a->a) where adhoc = maybe (error "wrong number") id instance Adhoc [Char] where adhoc = "hello, world" instance Adhoc (String->IO ()) where adhoc = print

Yes, of course taken to this extent it is bad, but I'm not suggesting this at all. In particular, we have well-chosen names for many functions, but not every container can use exact same interface (see, for example, the many discussions on "restricted monads"). So we can't reuse the same function name for similar concepts that have slightly different interfaces.

main :: IO () main = adhoc (adhoc (adhoc . Just :: Char -> Char) (adhoc :: String) :: String)

I hope this also demonstrates why it is usually a bad idea, even if it often looks good in theory. If you're not convinced yet, play with this kind of code in practice.

I do play with this kind of code in practice, in other languages. In practice, I don't see the kind of problems you are bringing up occur. However, those languages tend to be dynamically typed so I do get the occasional runtime type error. I'd much rather have a safe way of doing less typing than an unsafe way. As an example of this done correctly, in Ruby, you have Array#each: [1,2,3].each { |x| print x } Hash#each: { :foo => "hello", :bar => "world" }.each { |k, v| print v } etc. "each" corresponds to the idea of iterating over a container (foldM in Haskell) without being a slave to maintaining an identical API for each type. I maintain that in Haskell, trying to get this same generality often leads to abuse of the typeclass system for things where the types should trivially be determined at compile time.

The "well-typed programs don't go wrong" of static type checking depends on a clear separation of "right" and "wrong". If your use of types allows anything to be a valid program, minor variations in code will no longer be caught by the type system: at best, you'll get "missing instance", more likely you'll get "too many possibilities", and at worst, the code will simply do something different.

I don't think this is a strong argument. In practice most things have a single concrete type and helping the compiler with extra qualified names is just meaningless typing. I'm suggesting that in the case of this code:

import Data.Map as M x = map (+1) M.empty "map" should be inferred as "M.map" instead of being ambiguous.

There's already some minor work in the direction I am suggesting in record syntax, but it only works during pattern matching. I'd like "cx foo + cy foo" to work on any "foo" that has record members cx and cy that are members of Num, instead of needing to preface every record with the datatype name to avoid ambiguity. In particular I do NOT want each function in its own typeclass; the previous post saying:

foo x = map (bar x) should be rejected as ambiguous without a type signature somewhere (at least, if Data.Map is imported). This does give some amount of "action at a distance" where changing a file that is imported by another file can cause previously unambiguous code to become ambiguous, but that is already true! And this modification would make it less likely to be the case.

As to the argument that a "sufficiently smart IDE" would insert the "M." for me, I think that is flawed. First, there isn't a sufficiently smart IDE yet, and second, it'd be better for the type-aware IDE to tell me the types of things when I (for example) mouse over them, instead of helping me type longer things. -- ryan

On Sun, Aug 31, 2008 at 4:21 PM, Jonathan Cast wrote:

It seems as if you're proposing that

doubleSet :: Set.Set Int -> Set.Set Int doubleSet = map (*2)

doubleList :: [Int] -> [Int] doubleList :: map (*2)

work, but that you not be allowed to notice that the definitions are identical and substitute

double = map (*2)

for both definitions.

Yes, that's exactly what I am suggesting. This is especially important because Set cannot be made an instance of Functor because of the Ord restriction on the elements, so you can't generalize to fmap without redefining Functor as RestrictedFunctor or some such, which adds a ton of additional type-level programming that shouldn't be required for day-to-day work. I'm not against being able to use "double = map (*2)" generally, but the evidence I've seen says that the PL theory isn't there yet to do so without unacceptable performance penalties. (That definition violates the monomorphism restriction anyways).

Sorry, but I use Haskell specifically because I do *not* want to use C++.

I don't think "a language I dislike also has this feature" is a good argument against a feature. C++ also has named fields in records, and a standard I/O library. Should Haskell not have those either? -- ryan

As to the argument that a "sufficiently smart IDE" would insert the "M." for me, I think that is flawed. First, there isn't a sufficiently smart IDE yet,

I do believe there will be. What we do now is sort of putting down requirements ...

and second, it'd be better for the type-aware IDE to tell me the types of things when I (for example) mouse over them, instead of helping me type longer things.

That's been said before: an IDE might help in writing/changing code, but code should be readable without tool support. J.W.

Miguel Mitrofanov wrote:

Suppose you have different thing all named "insertWith". You've got one somewhere in your program; how do YOU know when looking at the code after a month or so, which one is this?

We already have that situation when classes are involved. If you replace specialised functions by abstractions provided classes, for instance mempty instead of Data.Structure.empty fmap instead of Data.Structure.map folds from Data.Foldable instead of a specialised module There certainly are more examples, but these are the most common. IMHO this doesn't make code much harder to read. mempty gives us some empty data structre, fmap applies a function to all its elements and folds do the same. It doesn't matter if we're talking about lists, sets or something else. And it has the huge advantage that you can replace a data structure by another (Maybe by [], [] by Set, ...) simply by changing a type signature and not the code.

Certainly, given a smart IDE you can ask it; but I think that code should be clear just when you look at it, without any action.

I think that - at least in the examples listed above - the code remains very clear.

[...]

Regards, Stephan -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr

Andrew Coppin wrote:

This quickly boils down to an argument along the lines of "Haskell doesn't support container neutrality very well", which as I understand it is already a known problem.

In all fairness, this complaint boils down to "there is no container typeclass" -- a nuisance but not a failure of the language per se. Likewise, there is no typeclass which gathers together the more useful similarities of ByteString and String. -- _jsn

Gwern Branwen wrote:

I think this would be very nice in GHCi, because there the situation is even *worse*.

I think we've all experienced importing Data.Map or Data.ByteString and discovering we need to tediously write it out in *full*, because we can't even do qualified imports of it!

Amen to that! Data.ByteString.Lazy.pack "Hello " Data.ByteString.Lazy.++ Data.ByteString.Lazy.pack "World!"

Oh, sorry, haven't noticed you said "ghcI". On 1 Sep 2008, at 00:59, Miguel Mitrofanov wrote:

Erm... Why can't we?

On 1 Sep 2008, at 00:43, Gwern Branwen wrote:

...

I think we've all experienced importing Data.Map or Data.ByteString and discovering we need to tediously write it out in *full*, because we can't even do qualified imports of it!

-- gwern BND fritz FKS 1071 Face government Tomahawk DREO IA O _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 2008 Sep 6, at 19:09, John Smith wrote:

Ryan Ingram wrote:

...

module Prob where import qualified Data.Map as M .... newtype Prob p a = Prob { runProb :: [(a,p)] } combine :: (Num p, Ord a) => Prob p a -> Prob p a combine m = Prob $ M.assocs $ foldl' (flip $ uncurry $ M.insertWith (+)) M.empty $ runProb m Do you see it? All those "M." just seem dirty to me, especially because the compiler should be able to deduce them from the types of the arguments.

May I humbly suggest a much simpler solution to your problem: if an identifier is ambiguous, the compiler will use the last import. So, in your example, the compiler will assume that any instance of empty is Data.Map.empty

I don't like that idea very much; if I reorder my imports the program semantics suddenly change?

Some means of using an imported module as the default namespace, and requiring the Prelude to be qualified, may also help.

You can already do this by importing Prelude explicitly, possibly with the NoImplicitPrelude language option. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH