January 2009 - Haskell-prime

[Proposal] Move most of Control.Monad to Control.Applicative
by Thomas Davie 12 Jul '09

12 Jul '09

Hi, Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives. Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible. My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives: mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () sequence :: (Applicative f) => [f a] -> f [a] sequence_ :: (Applicative f) => [f a] -> f () filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () replicateA :: (Applicative f) => Int -> f a -> f [a] replicateA_ :: (Applicative f) => Int -> f a -> f () when :: (Applicative f) => Bool -> f () -> f () unless :: (Applicative f) => Bool -> f () -> f () I may have missed some. Bob

4 6

Outlaw tabs
by Achim Schneider 11 Jul '09

11 Jul '09

I guess everyone knows why. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

11 17

Suggestion: Improved handling of overlapping imports
by Mathias Stearn 10 Jan '09

10 Jan '09

> | 1) Transitive Hiding > | If you hide something when importing a module it automatically hides > | identical imports. > > I don't like this because a 'hiding' clause on one import affects other imports. Yuk. Perhaps limit it to hiding implicit Prelude re-exports then. In each of those examples the Prelude is only listed to hide things. If the only import is: import System.IO hiding (putStrLn, hPutStrLn) There is no indication that System.IO.putStrLn is still in scope. Also the following three examples are valid haskell98 but are likely a programmer accident: import System.IO hiding (print, putStrLn) import Prelude hiding (putStrLn) import System.IO hiding (print) --assume no import Prelude line import System.IO hiding (print) import Prelude (print) None of these trigger a warning from GHC 6.8.3 with -Wall even though they will not do what the programmer likely intended. Note that the second will implicitly become the the third (if print is the only thing used from Prelude), and that the third has no reasonable meaning. (I think. Does it?) > | 2) Explicit Import Lists Take Precedence > | Any ambiguity should be resolved in favor of the module that has the > | name explicitly in its import list. ...This can be considered an extension of > | the current ImportShadowing > | (http://hackage.haskell.org/trac/haskell-prime/wiki/ImportShadowing) > | proposal if the current module is thought of as imported with > | everything explicit. > > I like this. It's in the same spirit as the ImportShadowing proposal, so if that proposal is accepted, then this one makes sense too. (If not, then think again.) Why don't you modify the ticket to add your proposal to it. I'll do that later today. I thought the ticket system was abandoned though? > | 3) Import A Shadowing B > | This actually adds a new import style which I think is the best solution: > | > | import System.IO.UTF8 shadowing System.IO > | import Data.Foldable shadowing Data.List > > I'm not keen on this. Not only is it new syntax, but it leads to the same repeats as you objected to earlier: Do you object to the idea in general or just this specific syntax? > import System.IO.UTF8 shadowing Prelude > import System.IO shadowing Prelude > import Prelude Well System.IO wouldn't have to shadow Prelude because their name collisions are re-exports and therefore, not ambiguous. Only if shadowing wasn't transitive would need to do something like: import System.IO.UTF8 shadowing (Prelude, System.IO) I was trying to come up with a better way to use a module designed to "overlay" on top others. This was the best syntax I could think of that makes overlay modules easy to use. At first I was considering a priority system where you could list the order to search for names, but shadowing seemed easier. The two common uses for these modules that I've seen are improvement and generalization. I see both as important in allowing the language to flexibly update. Consider something like the following to try a updated partial Prelude which still uses the old Prelude for things that haven't changed: import NewPrelude shadowing Prelude Is there a way to do this without introducing a new syntax (other than explicitly listing every name or importing Prelude qualified, neither of which are practical when testing an overlay module)? >| Mathias > Simon Mathias PS- I couldn't find a (non-strawman) proposal on the wiki about improving Unicode IO in Haskell'. Has that been discussed to death on the mailing list or should I start a new thread for it?

1 0

Suggestion: Improved handling of overlapping imports
by Mathias Stearn 08 Jan '09

08 Jan '09

I've noticed an annoying (anti)pattern when using modules that collide with other modules (esp with the prelude). I find this is most common with modules conflicting with Data.List or System.IO. I'm fairly new to Haskell (did a little last January with XMonad and Just now getting back into it) so maybe there is a better way to handle this. Example: import Data.Foldable (minimum, minimumBy, maximum, maximumBy) import Data.List hiding (minimum, minimumBy, maximum, maximumBy) import Prelude hiding (minimum, maximum) import System.IO.UTF8 (putStrLn, hPutStrLn) import System.IO hiding (putStrLn, hPutStrLn) import Prelude hiding (putStrLn) As you can see this can be quite annoying and is a disincentive to use improved or more general tools. Especially worrisome is that it is not obvious what you must hide from the Prelude. If you try to hide hPutStrLn or minimumBy you get an error. I found this led to a lot of trial and error (read: guess and check). I have a few ideas on how to solve this.The first two are using current syntax and simply doing what the programmer really meant. The third one is adding new syntax to allow a programmer to specify what they mean. All three should be able to work either together or separately. 1) Transitive Hiding If you hide something when importing a module it automatically hides identical imports. I cant think of a situation where this isn't what the user would want. This also seems easy to implement because the compiler already must know which functions are identical when checking for ambiguities. 2) Explicit Import Lists Take Precedence Any ambiguity should be resolved in favor of the module that has the name explicitly in its import list. An additional advantage here is that it offers some protection against a program breaking if a function is added to a module. This can be considered an extension of the current ImportShadowing (http://hackage.haskell.org/trac/haskell-prime/wiki/ImportShadowing) proposal if the current module is thought of as imported with everything explicit. 3) Import A Shadowing B This actually adds a new import style which I think is the best solution: import System.IO.UTF8 shadowing System.IO import Data.Foldable shadowing Data.List In each case all functions in A would shadow any function in B. I think this should behave like Transitive Hide where the identical Prelude functions would also be shadowed. A major advantage here is that it allows drop-in replacements for the standard libs to be easily used. A few things I could go either way on with this: 3.1) if minimum was explicitly imported from Data.List do we use it, Foldable.minimum, or do we error out? 3.2) if a module reexports Data.Foldable should it also reexport the shadowing? I could see this being useful on a big project where you import a module that reexports several modules shadowing the Prelude to create a specialized standard lib. 3.3) should there be a shadowing all? I may take a peek at GHC this weekend to see how easy it would be to add any of these as optional extensions. ~Mathias Stearn

2 1

Re: Suggestion: Syntactic sugar for Maps!
by Alson Kemp 03 Jan '09

03 Jan '09

>>> circularfunc: >>> > I suggest Haskell introduce some syntactic sugar for Maps. >>> > >>> > Python uses {"this": 2, "is": 1, "a": 1, "Map": 1} >>> > >>> > Clojure also use braces: {:k1 1 :k2 3} where whitespace is comma but >>> > commas are also allowed. >>> > >>> > I find the import Data.Map and then fromList [("hello",1), ("there", >>> > 2)] or the other form that I forgot(because it is to long!) to be to >>> > long... >>> > >>> > So why not {"hello": 1, "there": 2} ? A comment from the peanut gallery: I took circ's comment to be a suggestion that we adopt an _idiom_. That you can non-idiomatically accomplish the same thing in Haskell by defining some datatypes and functions doesn't seem to address the core suggestion. I'd rewrite circ's suggestion as follows: A bunch of modern and popular languages use the idiom of braces for maps (e.g. { 'a' => 1, 'b' => 2} ). Its simplicity has made maps vital parts of most programs. Much of the world has adopted this idiom and if Haskell adopts this syntactic sugar it will make it easier for others to adopt Haskell. Haskell is really interesting for a number of reasons. Map syntax isn't one of them but map syntax sugar would make adoption of Haskell that much easier. As I think Don S said, it's hard enough to adopt Haskell, so let's make it easier when possible... - Alson

4 3