- Haskell-Cafe - Haskell.org

haskellers.com: Keterconfig incorrect?
by Obscaenvs 04 Nov '12

04 Nov '12

Excerpt from source: "<h1>Welcome to Keter</h1><p>The hostname you have provided is not recognized.</p>". This after trying to login using Mozilla Persona: http://www.haskellers.com/auth/page/browserid/eyJhbGciOiJSUzI (Where I have shortened the string at the end) f

2 1

forall disappear from type signature
by oleg＠okmij.org 03 Nov '12

03 Nov '12

Takayuki Muranushi wrote: > Today, I encountered a strange trouble with higher-rank polymorphism. It > was finally solved by nominal typing. Was it a bug in type checker? lack of > power in type inference? > runDB :: Lens NetworkState RIB > runDB = lens (f::NetworkState -> RIB) (\x s -> s { _runDB = x }) > where f :: NetworkState -> RIB As it becomes apparent (eventually), RIB is a polymorhic type, something like type RIB = forall a. DB.DBMT (Maybe Int) IO a0 -> IO (StM (DB.DBMT (Maybe Int) IO) a0) The field _runDB has this polymorphic type. Hence the argument x in (\x s -> s { _runDB = x }) is supposed to have a polymorphic type. But that can't be: absent a type signature, all arguments of a function are monomorphic. One solution is to give lens explicit, higher-ranked signature (with explicit forall, that is). A better approach is to wrap polymorphic types like your did > newtype RIB = RIB (RunInBase (DB.DBMT (Maybe Int) IO) IO) The newtype RIB is monomorphic and hence first-class, it can be freely passed around. In contrast, polymorphic values are not first-class, in Haskell. There are many restrictions on their use. That is not a bug in the type checker. You may call it lack of power in type inference: in calculi with first-class polymorphism (such as System F and System Fw), type inference is not decidable. Even type checking is not decidable.

1 0

How to avoid T3 fonts in pdf generated with lhs2TeX?
by Andreas Abel 02 Nov '12

02 Nov '12

Hello, maybe someone has experience in publishing papers that use lhs2TeX and unicode characters with ACM, and has been in my situation before... Sheridan, who publishes for ACM, does not like T3 fonts. However, lhs2tex --agda does make use of T3 fonts via: \RequirePackage[utf8x]{inputenc} If I remove this, my unicode characters are garbled in the lhs2tex-generated code. Does anoyone know a smart workaround besides replacing all the unicode characters manually by some math symbols in the .tex file? Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

3 3

Unicode case (in)stability and Haskell identifiers.
by Richard O'Keefe 02 Nov '12

02 Nov '12

I've been putting together a proposal for Unicode identifiers in Erlang (it's EEP 40 if anyone wants to look it up). In the course of this, it has turned out that there is a technical problem for languages with case-significant identifiers. Haskell 2010 report, chapter 2. http://www.haskell.org/onlinereport/haskell2010/haskellch2.html varid → (small {small | large | digit | ' })\⟨reservedid⟩ conid → large {small | large | digit | ' } small → ascSmall | uniSmall | _ ascSmall → a | b | … | z uniSmall → any Unicode lowercase letter large → ascLarge | uniLarge ascLarge → A | B | … | Z uniLarge → any uppercase or titlecase Unicode letter This is actually ambiguous: any ascSmall is also a uniSmall and any ascLarge is also a uniLarge. I take it that this is intended to mean "any Unicode xxx letter other than an ASCII one" in each case. That's not the problem. The definition currently bans Hebrew, Arabic, Chinese, Japanese, all the Indic scripts, and basically only allows Latin, Greek, Coptic, Cyrillic, Glagolitic, Armenian, arguably Georgian, and Deseret (but not Shavian). That's not the problem either. The problem is that being a Unicode lower case, upper case, or title case letter is not a stable property. Unicode annex UAX#31 guarantees that X is a well-formed case-insensitive identifier now => X will always be a well-formed case-insensitive identifier and that X is a well-formed case-sensitive identifier now => X will always be a well-formed case-sensitive identifier What it does NOT guarantee is that it will continue to be begin with the same *case* or even that a letter will continue to be classified as a letter. So it is at least technically possible for a valid Haskell 2010 varid (conid) to turn into a conid (varid) or even cease to be a legal Haskell identifier at all. Unicode standard Annex UAX#31 guarantees stability of being-an-identifier by having an exceptional set for any letter that stops being a letter to go into. For example, there are SCRIPT CAPITAL {B,E,F,H,I,L,M,P,R} characters, all of which are capital letters except for SCRIPT CAPITAL P, which is a symbol, but it's in the exception set so it's still OK to use. All of the SCRIPT CAPITAL letters were in General Category So in Unicode 1.1.5 (the earliest for which online data is available). In Unicode 2.1.8, all of them were Lu except for SCRIPT CAPITAL P, which was Ll. By Unicode 3.0.0, SCRIPT CAPITAL P was back to So. Some time later it switched over to Sm. So we've had SCRIPT CAPITAL P - not a letter (1.1.5) - is a lower case letter (2.1.8) - not a letter again (3.0.0) at least according to the on-line UnicodeData-<version>.txt files. Putting ℘ into the exceptional set means that a UAX#31 identifier may still contain it, but not so a Haskell one. There are two aspects to this instability. (1) Because Haskell hews its own line instead of tailoring UAX#31 the way Ada and Python do, Haskell cannot benefit from the UAX#31 stability guarantee. There _has_ been a character that used to be legal in a Haskell identifier that is not now. That's Haskell's problem, not Unicode's, and the Haskell community does not have to wait for anyone else to address is. (2) Even if you adopt one of the UAX#31 definitions verbatim, the case distinction Haskell needs to make is not stable. It appears that nobody who worked on UAX#31 was thinking about languages like Prolog, Erlang, Clean, Haskell, F#, or Scala, and that if the Unicode Consortium are told of the problem, they will probably be happy to add some sort of "don't break these languages" guideline. Next week I intend to submit a proposal to the Unicode consortium to consider this issue. Would anyone care to see and comment on the proposal before I send it to Unicode.org? Anyone got any suggestions before I begin to write it? For the sake of argument, suppose that we are going to stick with Xid_Start Xid_Continue* for the union of variables and atoms (which is pretty much what Ada and Python do), and the sole issue of concern is that there should be a stable way to classify such a token as "beginning with default case" or "beginning with marked case".

2 1

[Security] Put haskell.org on https
by Niklas Hambüchen 02 Nov '12

02 Nov '12

(I have mentioned this several times on #haskell, but nothing has happened so far.) Are you aware that all haskell.org websites (hackage, HaskellWiki, ghc trac) allow unencrypted http connections only? This means that everyone in the same Wifi can potentially - read you passwords for all of these services - abuse your hackage account and override arbitrary packages (especially since hackage allows everybody to override everything) I propose we get an SSL certificate for haskell.org. I also offer to donate that SSL certificate (or directly create it using my Startcom account). Niklas

17 34

[solved] forall disappear from type signature
by Takayuki Muranushi 02 Nov '12

02 Nov '12

Today, I encountered a strange trouble with higher-rank polymorphism. It was finally solved by nominal typing. Was it a bug in type checker? lack of power in type inference? or lack of my understanding? I'll submit this in hope that it will at least result in better GHC error message some day: My following code https://github.com/sugoi/sugoi/blob/0aec19b29274ddb7c5ae46b9b733e91bae0790b… > runDB :: Lens NetworkState RIB > runDB = lens (f::NetworkState -> RIB) (\x s -> s { _runDB = x }) > where f :: NetworkState -> RIB Didn't typecheck with following error: Sugoi/Types.hs:38:15: Couldn't match expected type `RIB' with actual type `DB.DBMT (Maybe Int) IO a0 -> IO (StM (DB.DBMT (Maybe Int) IO) a0)' Expected type: NetworkState -> RIB Actual type: NetworkState -> DB.DBMT (Maybe Int) IO a0 -> IO (StM (DB.DBMT (Maybe Int) IO) a0) In the first argument of `lens', namely `(f :: NetworkState -> RIB)' In the expression: lens (f :: NetworkState -> RIB) (\ x s -> s {_runDB = x}) How come an expression `(f :: NetworkState -> RIB)' is not of type NetworkState -> RIB ? When I changed the definition of runDB as follows, > runDB = lens (\NetworkState{_runDB = x} -> x) (\x s -> s { _runDB = x }) The source of error was more clear: Expected type: DB.DBMT (Maybe Int) IO a1 -> IO (StM (DB.DBMT (Maybe Int) IO) a1) Actual type: DB.DBMT (Maybe Int) IO a -> IO (StM (DB.DBMT (Maybe Int) IO) a) So, ghc couldn't unify these two types. By using the nominal typing, namely > - type RIB = RunInBase (DB.DBMT (Maybe Int) IO) IO > + newtype RIB = RIB (RunInBase (DB.DBMT (Maybe Int) IO) IO) the problem was solved. Always grateful to haskell-cafe from being there, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

1 0

Haskell Weekly News: Issue 249
by Daniel Santa Cruz 01 Nov '12

01 Nov '12

Welcome to issue 249 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of October 21 to October 27, 2012. Quotes of the Week * johnw: ah terminology, just when you think you know something, they redefined "know"... * lispy: The crappy thing about using partial fun*** Exception: Pattern match failure * shachaf: This Useful Information information brought to you by: ghci, and: the letter t * edwardk: i should have picked a better name to minimize confusion cmccann: huh. that's not something I ever expected to hear edwardk say * beaky: why did they settle on bitshiftrightassign (>>=) for monadic bind? Top Reddit Stories * Why is this simple text processing program so much slower than in dynamic languages? Domain: honza.ca, Score: 64, Comments: 189 On Reddit: [1] http://goo.gl/jW5ow Original: [2] http://goo.gl/pPzIb * Fay slides Domain: fay-lang.org, Score: 50, Comments: 42 On Reddit: [3] http://goo.gl/0UM4T Original: [4] http://goo.gl/h8iZE * Haskell for all: "Hello, core!" Domain: haskellforall.com, Score: 48, Comments: 6 On Reddit: [5] http://goo.gl/qXRd2 Original: [6] http://goo.gl/9cBeo * Haskell job opening at Functor AB Domain: alpmestan.com, Score: 35, Comments: 5 On Reddit: [7] http://goo.gl/hQmoa Original: [8] http://goo.gl/ASA9c * Enemy of the Mutable State Domain: ozonehouse.com, Score: 32, Comments: 10 On Reddit: [9] http://goo.gl/Wn3Yv Original: [10] http://goo.gl/r18by * Gloss(ish) and Fay: An Example Domain: zelda.designacourse.com, Score: 29, Comments: 7 On Reddit: [11] http://goo.gl/rtR9Y Original: [12] http://goo.gl/1cF0z * Yesodweb: Future work to improve the performance of Warp Domain: yesodweb.com, Score: 25, Comments: On Reddit: [13] http://goo.gl/0YF64 Original: [14] http://goo.gl/fq7ds * (a,b,c,d) as sugar for (a,(b,(c,d))) ? Domain: self.haskell, Score: 23, Comments: 37 On Reddit: [15] http://goo.gl/cc30R Original: [16] http://goo.gl/cc30R * Using Cloud Haskell in HPC Cluster Domain: malcodigo.blogspot.com.es, Score: 23, Comments: On Reddit: [17] http://goo.gl/LxmqY Original: [18] http://goo.gl/ycmZr * Haskell Platform 2012.4.0.0 release candidates Domain: trac.haskell.org, Score: 23, Comments: 3 On Reddit: [19] http://goo.gl/B4MNc Original: [20] http://goo.gl/Q4fHP Top StackOverflow Questions * Concrete example showing that monads are not closed under composition (with proof)? votes: 24, answers: 3 Read on SO: [21] http://goo.gl/sys7F * Why is there no IO transformer in Haskell? votes: 15, answers: 2 Read on SO: [22] http://goo.gl/04Xc7 * Is it possible to make GHC optimize (deforest) generic functions such as catamorphisms? votes: 14, answers: 1 Read on SO: [23] http://goo.gl/f4ZlU * Confused by the meaning of the 'Alternative' type class and its relationship to other type classes votes: 13, answers: 5 Read on SO: [24] http://goo.gl/RXNuV * How to add fields that only cache something to ADT? votes: 13, answers: 0 Read on SO: [25] http://goo.gl/FjLlX * How to reliably compare runtime of Haskell and C? votes: 10, answers: 1 Read on SO: [26] http://goo.gl/R7whA * Currying Product Types votes: 10, answers: 3 Read on SO: [27] http://goo.gl/7gxIS * Modular Program Design - Combining Monad Transformers in Monad Agnostic functions votes: 9, answers: 2 Read on SO: [28] http://goo.gl/8rh1B * Is there a nicer way to apply a function to both elements of a pair in a list than a list comprehension? votes: 9, answers: 3 Read on SO: [29] http://goo.gl/JF3p5 * How unpacking strict fields goes together with polymorphism? votes: 9, answers: 1 Read on SO: [30] http://goo.gl/58MuT Until next time, Daniel Santa Cruz References 1. http://honza.ca/2012/10/haskell-strings 2. http://www.reddit.com/r/haskell/comments/120h6i/why_is_this_simple_text_pro… 3. http://fay-lang.org/fay-talk/ 4. http://www.reddit.com/r/haskell/comments/11yrpi/fay_slides/ 5. http://www.haskellforall.com/2012/10/hello-core.html 6. http://www.reddit.com/r/haskell/comments/11vuzz/haskell_for_all_hello_core/ 7. http://alpmestan.com/posts/2012-10-23-haskell-job-opening-at-functor.html 8. http://www.reddit.com/r/haskell/comments/11yf8c/haskell_job_opening_at_func… 9. http://www.ozonehouse.com/mark/enemy/ 10. http://www.reddit.com/r/haskell/comments/125zt0/enemy_of_the_mutable_state/ 11. http://zelda.designacourse.com/codeworld.html 12. http://www.reddit.com/r/haskell/comments/126vdk/glossish_and_fay_an_example/ 13. http://www.yesodweb.com/blog/2012/10/future-work-warp 14. http://www.reddit.com/r/haskell/comments/11w7wv/yesodweb_future_work_to_imp… 15. http://www.reddit.com/r/haskell/comments/11ysa5/abcd_as_sugar_for_abcd/ 16. http://www.reddit.com/r/haskell/comments/11ysa5/abcd_as_sugar_for_abcd/ 17. http://malcodigo.blogspot.com.es/2012/10/using-cloud-haskell-in-hpc-cluster… 18. http://www.reddit.com/r/haskell/comments/122m6y/using_cloud_haskell_in_hpc_… 19. http://trac.haskell.org/haskell-platform/wiki/ReleaseCandidates 20. http://www.reddit.com/r/haskell/comments/124kje/haskell_platform_2012400_re… 21. http://stackoverflow.com/questions/13034229/concrete-example-showing-that-m… 22. http://stackoverflow.com/questions/13056663/why-is-there-no-io-transformer-… 23. http://stackoverflow.com/questions/13099203/is-it-possible-to-make-ghc-opti… 24. http://stackoverflow.com/questions/13080606/confused-by-the-meaning-of-the-… 25. http://stackoverflow.com/questions/13098448/how-to-add-fields-that-only-cac… 26. http://stackoverflow.com/questions/13009728/how-to-reliably-compare-runtime… 27. http://stackoverflow.com/questions/13080074/currying-product-types 28. http://stackoverflow.com/questions/13007123/modular-program-design-combinin… 29. http://stackoverflow.com/questions/13022720/is-there-a-nicer-way-to-apply-a… 30. http://stackoverflow.com/questions/13098375/how-unpacking-strict-fields-goe…

1 0

Comparing Haskell and Darcs
by Henk-Jan van Tuyl 01 Nov '12

01 Nov '12

L.S., I just found a site that compares o.a. Haskell to other languages[0] and Darcs to other version control systems[1]: Hammer principle. Haskell scores quite good, Darcs could do better. Regards, Henk-Jan van Tuyl [0] http://hammerprinciple.com/therighttool/items/haskell [1] http://hammerprinciple.com/versioncontrol/items/darcs -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Deriving settings from command line, environment, and files
by David Thomas 01 Nov '12

01 Nov '12

Is there a library that provides a near-complete solution for this? I looked around a bit and found many (many!) partial solutions on hackage, but nothing that really does it all. In coding it up for my own projects, however, I can't help but feel like I must be reinventing the wheel. What I want is something that will process command line options (this seems to be where most packages are targetted), environment variables, and settings files (possibly specified in options), and override/default appropriately. Did I miss something? If not, I'd like to see about fixing the situation, but very much want to avoid the whole "There were X libraries that didn't quite do it right; now there's X+1!" thing. Are there any opinions as to which of the many libraries is likely the best starting point if I'm going to contribute to one of them?

3 2

Looking for advice on modelling a 3-way merge (with varying strategies)
by Oliver Charles 31 Oct '12

31 Oct '12

Hello, I'm currently trying to implement a way 3 way merge, that is dispatched on type. Essentially, I want to be able to say "I have this large data type which is a product of various other types - here's how to merge it". By 3 way merge, I mean that I have a 'new' value, a 'current' value and a 'common ancestor' value. So far I have: import Control.Applicative import Data.Monoid newtype Merge a = Merge { runMerge :: Either [String] a } instance Functor Merge where fmap f a = Merge $ fmap f $ runMerge a instance Applicative Merge where pure = Merge . Right (Merge (Right f)) <*> (Merge (Right a)) = Merge $ Right $ f a (Merge (Right _)) <*> (Merge (Left c)) = Merge $ Left $ c (Merge (Left c)) <*> (Merge (Left c')) = Merge $ Left $ c <> c' (Merge (Left c)) <*> _ = Merge $ Left $ c ok :: a -> Merge a ok = pure failMerge :: String -> Merge a failMerge x = Merge $ Left [x] So far so good, so I can add my first merge strategy: mergeEq :: Eq a => String -> a -> a -> a -> Merge a mergeEq lbl new current ancestor | current == new = ok new | current == ancestor = ok new | new == ancestor = ok current | otherwise = failMerge lbl And we can make use of this to build more complicated merge strategies: data Person = Person { name :: String, surname :: String } deriving (Show) mergeEqOn :: Eq a => (b -> a) -> String -> b -> b -> b -> Merge a mergeEqOn l lbl n c a = mergeEq lbl (l n) (l c) (l a) mergePerson :: Person -> Person -> Person -> Merge Person mergePerson new current ancestor = Person <$> mergeEqOn name "name" new current ancestor <*> mergeEqOn surname "surname" new current ancestor >>> runMerge $ mergePerson Person { name="Steve", surname="Bobman" } Person { name="Joe", surname="Obman" } Person { name="oe", surname="Obman" } Left ["name"] >>> runMerge $ mergePerson Person { name="Steve", surname="Bobman" } Person { name="Joe", surname="Obman" } Person { name="Joe", surname="Obman" } Right (Person {name = "Steve", surname = "Bobman"}) Everything does exactly what I want, but it doesn't smell as good as I expect from Haskell. Firstly, all my primitives or operations take 3 arguments that have to be threaded in a very specific pattern. If I accidently call mergeEq ancestor current new, I've ran things in the wrong order and I'm Gonna Have a Bad Time. So that's no good. Secondly, is there a better way of labelled parts of a merge? I suspect not, as at some point I need a human readable display, but I did wonder about using a lens as a label, and then mapping lenses to human readable names later -- but that will require a bit of newtyping in order to provide the Eq instance, or maybe i make a HumanLens type which is a lens and a name?). Finally, I'm currently a little obsessed with the idea of building applicatives from the composition or product of other applicatives - can I use this trick here? I initially used 'Compose ((,) [String]) Maybe a' but this means it's possible to have (["Conflicts"], Just "But success!"), which is nonsense. I'd love to hear your thoughts! - ocharles

1 0