- Haskell-Cafe - Haskell.org

fun fact: value of truncate -Infinity depends on optimisation level
by Johannes Waldmann 26 Jul '15

26 Jul '15

Just for general amusement - I was debugging very strange behaviour in a straightforward deterministic program, where the output value seemed to depend on ghc's optimization level. Well, it turned out that I (accidentally) computed truncate (logBase 2 0) :: Int, and that's 0 with -O0, but -9223372036854775808 with -O2. https://github.com/jwaldmann/matchbox/issues/19

1 0

ANN: haddock-2.16.1
by Mateusz Kowalczyk 24 Jul '15

24 Jul '15

Hi, We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I inline the changelog at the bottom. It should work fine with 7.10.x GHC family. The packages are already on Hackage: haddock for the executable, haddock-api for the guts and use from Haskell and haddock-library which is the comment parser. It should also be shipping with GHC 7.10.2. I think two things are worth mentioning before: * The pending mathjax PR[1] is going to be included in future release of Haddock. As it is likely to break the interface file version, I am putting it off a bit to bundle with other possibly interface-breaking changes. * Our GSOC student has successfully completed first part of his project[2]. It involves native source code highlighting and perhaps more excitingly, source hyperlinking: you should now be able to click on identifiers to be taken to their definitions. This change is not in 2.16.1 as it is rather recent so we erred on the side of safety when picking what to release with GHC 7.10.2. You can try it by building current Haddock master, should work with 7.10.x family. As usual, if you want to contribute, please do so on GitHub. We're also on IRC under #haddock. Thanks! Changes in version 2.16.1 * Don't default to type constructors for out-of-scope names (#253 and #375) * Fix Hoogle display of constructors (#361) * Fully qualify names in Hoogle instances output (#263) * Output method documentation in Hoogle backend (#259) * Don't print instance safety information in Hoogle (#168) * Expand response files in arguments (#285) * Build the main executable with -threaded (#399) * Use SrcSpan of declarations for inferred type sigs (#207) * Fix cross-module instance locations (#383) * Fix alignment of Source link for instances in Firefox (#384) [1]: https://github.com/haskell/haddock/pull/397 [2]: https://github.com/haskell/haddock/pull/410 -- Mateusz K.

6 5

Re: [Haskell-cafe] Discussion: The CLOEXEC problem
by Donn Cave 23 Jul '15

23 Jul '15

Quoth David Turner <dave.c.turner(a)gmail.com>, ... > Non-inheritable-by-default makes sense to me - if you forget to clear > FD_CLOEXEC when you meant to then your program breaks loudly and obviously; This is where we differ. First, it isn't fair to say we "forget" to clear FD_CLOEXEC, if in pre-existing software we didn't have a CLOEXEC bit to clear. Rather, in the existing set of applications that have an exec - whether in Haskell code or not - we can expect that some subset of them will start to behave differently. Maybe behave better, but in any case likely a surprise to everyone because we've reversed the default on some large subset of file descriptors. And I think it's very optimistic to predict that the breakage will be obvious - the obvious effects will naturally be obvious, but I personally am not up to accounting for all non-obvious cases. And there's the other FDs - inherited, non-Haskell, sockets - so we still need another solution if we're serious about fixing the problem. Donn

1 0

Bibliographic references on advantages of functional languages for refactoring
by Nicola Gigante 23 Jul '15

23 Jul '15

Hi all, I’m writing my master thesis, which is not itself about functional programming but I use Haskell as the language chosen for the implementation of whatever I’m talking about. To motivate the choice more than “I like the language” I’m arguing that since I’m implementing experimental stuff and I’ll need to change the code and refactor very often, a strongly typed language is what I need. I wrote this sentence: "Strongly-typed programming eases the refactoring process by leveraging the compiler to spot wrong transformations before they turn into runtime bugs” Since this thesis is not itself about functional programming this sentence needs to be backed by something. In other words I need to cite some published paper where this is said/surveyed/proved/whatever. So the question: can you help me find referentiable published work relative to how strongly-typed functional programming eases refactoring? A survey or some case-study report or some functional pearl, dunno. Thank you very much in advance, Nicola

4 4

ghc-mod: cannot satisfy yesod-static
by Denis Shevchenko 22 Jul '15

22 Jul '15

Hi all! I'm trying to use ghc-mod with my Yesod-project, but I get this error: $ ghc-mod ghc-mod: <command line>: cannot satisfy -package-id yesod-static-1.4.0.4-c893310d859222b1b20461f9fdb4d916 (use -v for more information) My project builds correctly. In my .cabal-file I see this dependency: build-depends: base >= 4 && < 5 , yesod >= 1.4.0 && < 1.5 , yesod-core >= 1.4.0 && < 1.5 , yesod-auth >= 1.4.0 && < 1.5 , yesod-static >= 1.4.0 && < 1.5 ... I use LTS-2.18, and I see this package in ~/.stack/snapshots/x86_64-osx/lts-2.18/7.8.4/lib/x86_64-osx-ghc-7.8.4/: ... yesod-static-1.4.0.4 ... So, what can I do? Please help me. Sincerely, Denis.

2 1

ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
by Ivan Lazar Miljenovic 22 Jul '15

22 Jul '15

I'm pleased to announce that I've (finally!) just released version 5.5.2.0 of [fgl]. Major changes in this release include a test suite, refactorings, code clean-ups and the following potentially breaking changes (in that they were previously unspecified or incorrect): - `nodeRange` and `nodeRangeM` for the various graph data structures erroneously returned `(0,0)` for empty graphs (making them indistinguishable from graphs containing the single node `0`). They now match the default implementation of throwing an error. - The behaviour of `delLEdge` when dealing with multiple edges was unspecified; it now deletes only a single edge and the new function `delAllLEdge` deletes all edges matching the one provided. All changes can be found in the changelog. [fgl]: https://hackage.haskell.org/package/fgl Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e. the "I finally build against the version on Hackage" release). [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Fwd: Re: Strange "ambiguity" problems thanks to GADTs
by Alexander Eyers-Taylor 22 Jul '15

22 Jul '15

Sorry I forgot to reply to the list Alex -------- Forwarded Message -------- Subject: Re: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs Date: Wed, 22 Jul 2015 13:24:56 +0100 From: Alexander Eyers-Taylor <aeyerstaylor11(a)gmail.com> To: Andres Loeh <mail(a)andres-loeh.de> Hi In this case what happens in the type checker is that after checking the start of the let we give the variable e1 a type (say abt0a) Then we enter the case. When entering the case, as SFun introduces a constaint (SFun is actually of type (a ~ Maybe j) => Sing a). As we have a constraint we cannot then unify the variables. The reason we can't unify is that we cant tell that (a ~ Maybe j) does not imply (abt0 ~ abt'). In GHC 6.12 the old type inference algotrithm was used. This had some problems as it didn't always infer a priciple type for GADTs. The new inference algorithm OutsideIn does this in a more principled way. In the non-indexed versions when we do the pattern match no constaints are introduced so we can typecheck as usual Alex On 22/07/15 07:59, Andres Loeh wrote: > Hi. > > I've drastically reduced the example. This program triggers the same error: > >> {-# LANGUAGE GADTs, KindSignatures #-} >> >> data Sing :: * -> * where >> SFun :: Sing (Maybe j) >> >> class WellTypedABT (abt :: * -> *) where >> typeOf :: abt a -> Sing a >> >> inferType :: (WellTypedABT abt') => abt a -> abt' a >> inferType e1 = >> let e1' = inferType e1 >> in case typeOf e1' of >> SFun -> e1' > Btw, this compiles fine with ghc-6.12 (as does a version of the > original program if we replace the data kinds involved by equivalent > kind-*-datatypes). > > Cheers, > Andres > > On Wed, Jul 22, 2015 at 1:11 AM, wren romano <winterkoninkje(a)gmail.com> wrote: >> On Wed, Jul 8, 2015 at 9:14 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> I think GADTs are a red herring here -- this is the classic show/read ambiguity dressed up. In the code below, how should GHC determine the type of e1' or e2'? There's no way to know. >> Except that when I erase the indices, everything works just fine: >> >> >> {-# LANGUAGE KindSignatures, GADTs #-} >> >> data Type = Fun Type Type >> >> data AST :: * -> * where >> App :: ast -> ast -> AST ast >> >> class ABT (abt :: *) where >> view :: abt -> AST abt >> unview :: AST abt -> abt >> >> class WellTypedABT (abt :: *) where >> unviewWT :: Type -> AST abt -> abt >> typeOf :: abt -> Type >> >> data TypeCheckMonad a = TCM { unTCM :: a } >> >> instance Functor TypeCheckMonad where >> fmap f = TCM . f . unTCM >> >> instance Applicative TypeCheckMonad where >> pure = TCM >> TCM f <*> TCM x = TCM (f x) >> >> instance Monad TypeCheckMonad where >> return = pure >> TCM x >>= k = k x >> >> inferType >> :: (ABT abt, WellTypedABT abt') >> => abt >> -> TypeCheckMonad abt' >> inferType e0 = >> case view e0 of >> App e1 e2 -> do >> e1' <- inferType e1 >> case typeOf e1' of >> Fun typ2 typ3 -> do >> e2' <- inferType e2 >> return . unviewWT typ3 $ App e1' e2' >> >> >> -- >> Live well, >> ~wren >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

1 0

Why there is no instance Generic Word?
by Alexey Vagarenko 21 Jul '15

21 Jul '15

There is instance Generic Int, but not Generic Word. Also no Generic instances for Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64.

1 0

Message passing library
by Corentin Dupont 21 Jul '15

21 Jul '15

Hello, what would you recommend as a message passing library? Essentially, I would to replace this library http://hackage.haskell.org/package/eprocess by something more mainstream. It is used in Hint-server: http://hackage.haskell.org/package/hint-server Thanks! Corentin

6 10

Several Experienced Developers for Advanced Functional Programming - Ocaml, Haskell, Scala - compiler technology, LLVM, C, etcetera, and Martin-Löf type theory, static analysis, our main target is embedded software
by Johan Glimming 20 Jul '15

20 Jul '15

Hi folks, There are openings at Functor, Sweden, including also remote work, except for Scala consultants who must immediately relocate: Do you want to be part of the journey as the Functor startup research spin-off innovates the future of software engineering? Do you want to make a difference? Do you want to devote your talents where it can have incredible impact on the entire software industry? Functor, Sweden, is again looking for brilliant minds, essentially co-founders as a generous equity program will after a certain threshold time make sure developers, building the company indeed, also own what they are building. Please apply on LinkedIn, closing soon take action if interested: https://www.linkedin.com/jobs2/consumer/overview/60296037 We use Haskell, OCaml, LLVM and our tools are closely tied to the C programming language and indeed to functional programming. Embedded software market is one target market, and skills in compiler design, type systems and operational semantics is key to our teams though we look for optimised teams as a whole, and your particular skill set may or may not include a PhD, but surely industrial experience. We have openings for Research Engineers and have some renown Research Engineers already. Research collaboration is key to our success and projects planned including a large EU project CONSTRUCTOR next year. We have strong industrial partners and some very high-profile customers internationally. The customer-driven journey is still at an early stage, while founded in 2011, and your contributions would be key to our success. Scala consultants will be sent straight from the top down into projects at Ericsson for very challenging work. For these three consultants we require an exceptionally strong background with Scala projects as we team up with Typesafe and secure projects that can only be matched by exceptional Scala developers. Our Functor Scalor™ is oriented somewhat differently than Scala, see www.domainspecific.org<http://www.domainspecific.org> for some initial information on that products that appeals to very large companies at this stage, while Functor Prevent™ is suitable for just about any software development projects, currently doing static analysis with dependent types and automatic testing for C code, such as the Erlang code base, Twitter’s MySQL branch or embedded software at large, see www.functorprevent.com<http://www.functorprevent.com> or www.static-analysis.org<http://www.static-analysis.org>, and also the standalone tool www.functor.se/prevent<http://www.functor.se/prevent> which secures systems including a project at a customer with a range of 100 MEUR/each equipment investments, all relying on the VxWorks C code where our Functor Prevent™ delivers its value to prevent up to 50% of the bugs in certain projects, already with its current R1 feature set! [cid:BA7C0361-C40F-4993-820E-420FB0B1543B@in.functor.se]<https://www.linkedin.com/jobs2/consumer/overview/60296037> Instructions and information, please read carefully the last paragraph on what we need to evaluate candidates adequately: https://www.linkedin.com/pulse/openings-functional-programmers-swedish-star… Read up with links above to our webpages (last link), and postings on LinkedIn and Facebook: https://www.linkedin.com/pulse/future-software-engineering-johan-glimming?t… Facebook eg: http://www.facebook.com/functor Webpage has more information, linked to one the main posting above for some key webpages to check: www.functor.se<http://www.functor.se> [3230fbd.png]<https://www.linkedin.com/pulse/openings-functional-programmers-swedish-star…> Welcome to apply and be part of an exciting journey ahead with a very important mission to turn software engineering into a discipline at last, backed by industrial productification for years and R&D that have never reached the software industry due to its inherent complexity, now mature, and now with proven market fit with Functor Prevent™ and Functor Scalor™ being used in heavy duty projects but much more to come! It’s Martin-Löf / dependent type theory inside our tools. Best, Johan — Dr Johan Glimming Chief Executive Officer at Functor AB, Chairman at Functor Group AB Request a meeting or schedule a call: www.doodle.com/glimming<http://www.doodle.com/glimming> Mobile: +46-76-7646000<tel:+46-76-7646000> Direct: +46-8-55005505<tel://+46-8-55005505> Main: +46-8-55005500<tel:+46-8-55005500> Assistant: +46-8-55005501<tel://+46-8-55005501> Skype: glimming<skype://glimming> Twitter: @glimming<https://www.twitter.com/glimming> LinkedIn: se.linkedin.com/in/glimming<http://se.linkedin.com/in/glimming> Functor AB, Box 7070, 164 07 Kista, SWEDEN<x-apple-data-detectors://3/1> Web: www.functorgroup.com<http://www.functorgroup.com/> Twitter: @functors<https://www.twitter.com/functors/> UK tel: +44-1223-911400<tel:+44-1223-911400> US tel: +1-(415)-513-0090 — ANY INFORMATION DISCLOSED DIRECTLY OR INDIRECTLY IN, OR IMPLIED BY, THIS EMAIL, INCLUDING ATTACHMENTS, EXTERNAL REFERENCES OR APPENDICES, IS STRICTLY CONFIDENTIAL AND/OR PROPRIETARY AND IS INTENDED ONLY FOR USE BY FUNCTOR GROUP AB, SWEDEN, REG. NR. 556972-3736, AND ITS SUBSIDIARIES – OR BY A THIRD PARTY STRICTLY IN FUNCTOR GROUP AB’S OR ITS SUBSIDIARIES' DIRECT INTEREST, BUT ONLY FOR THOSE PARTIES LISTED AS DESIGNATED RECIPIENTS AND PARTIES WITH PRIOR WRITTEN PERMISSION. ANY UNAUTHORISED RELEASE OR USE OF THIS INFORMATION IS PROHIBITED AND PUNISHABLE BY LAW. YOU SHOULD IMMEDIATELY UPON RECEIVING THIS E-MAIL, YOU SHOULD IMMEDIATELY CONTACT THE SENDER OR FUNCTOR. OUR LAWYERS AT LEGAL(a)FUNCFTORGROUP.COM<mailto:LEGAL@FUNCFTORGROUP.COM> OR +46-8-55005517 ARE AVAILABLE AS NEEDED.

1 0