News aggregator

I print myself

Haskell on Reddit - Tue, 07/07/2015 - 3:06am
main=putStr$(\x->x++show x)"main=putStr$(\\x->x++show x)" submitted by Florian939
[link] [12 comments]
Categories: Incoming News

Strange "ambiguity" problems thanks to GADTs

haskell-cafe - Tue, 07/07/2015 - 1:28am
Hi all, In my latest project I've been using a bunch of GADTs, which unfortunately disables let-polymorphism (i.e., where-polymorphism) in the most annoying way. For the most part I've been able to hack around that limitation via judicious use of ScopedTypeVariables, but I've run into an issue that I can't for the life of me figure out why GHC doesn't like it. I have something like the following function, where < at >a< at > and < at >b< at > happen to be GADTs: foo :: (A a, B b) => a i -> M (b i) foo a = case view a of ... SomePattern a1 a2 -> do b1 <- foo a1 b2 <- foo a2 return . unview $ SomePattern b1 b2 It seems to me that the recursive calls should work just fine, using the same < at >b< at > as we'll ultimately be returning. However, for some reason GHC complains about the recursive calls using some other < at >b0< at > can can't deduce < at >B b0< at > from < at >B b< at >. Why doesn't GHC unify these two types? How can I force them to unify without adding type annotations at every recurs
Categories: Offsite Discussion

Is Greece a Monad?

Haskell on Reddit - Mon, 07/06/2015 - 11:21pm

Is it a monad, in the sense that it binds all the money and returns ()? I am Greek so feel free to write anything you like...

submitted by nikosquant
[link] [comment]
Categories: Incoming News

Request for maintainer(s) : language-javascript /hjsmin

haskell-cafe - Mon, 07/06/2015 - 7:42pm
Hi all I am the author of language-javascript and its companion hjsmin. Unfortunately I do not use the libraries myself, and I am falling behind in maintaining them, all the more so with the new ECMASCRIPT spec out. So I am calling for volunteers to take over maintenance of these two packages. Regards Alan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

OCL 2015: Final Call for Papers - Only 10 Days Left

General haskell list - Mon, 07/06/2015 - 7:12pm
(Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now prepare your submission for the OCL workshop! CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of su
Categories: Incoming News

OCL 2015: Final Call for Papers - Only 10 Days Left

haskell-cafe - Mon, 07/06/2015 - 7:12pm
(Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now prepare your submission for the OCL workshop! CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of su
Categories: Offsite Discussion

Problems with type families

haskell-cafe - Mon, 07/06/2015 - 6:20pm
Hi All! Consider the following definitions: type family TFunIn t e type family TFunOut t e data IdT data ComposeT t1 t2
Categories: Offsite Discussion

New Functional Programming Job Opportunities

haskell-cafe - Mon, 07/06/2015 - 5:00pm
Here are some functional programming job opportunities that were posted recently: Senior Developer at Elsen, Inc. http://functionaljobs.com/jobs/8840-senior-developer-at-elsen-inc Cheers, Sean Murphy FunctionalJobs.com
Categories: Offsite Discussion

I'd appreciate help figuring out how to use polymorphism in a simple case

Haskell on Reddit - Mon, 07/06/2015 - 3:31pm

I think I know why this code is failing (I'm guessing because the typechecker sees that t can be an Int or a String and thinks I've made a mistake). What I'd like to know is how I can get something like this working. I think the code explains my basic case pretty well, so I'll let it do the work:

data TestMode = A | B data Test = Test { a :: String, b :: Int, mode :: TestMode } getProperty :: Show t => Test -> t getProperty test = case mode test of A -> a test B -> b test main = do let t = Test { a = "yes!", b = 5, mode = A } print $ getProperty t

I leave the error in the comments to make this a bit shorter to read. My goal is to not do a lot of duplicate code. The following script works, but if I have to do a lot of print operations like this it gets unwieldy:

data TestMode = A | B data Test = Test { a :: String, b :: Int, mode :: TestMode } main = do let t = Test { a = "yes!", b = 5, mode = A } case mode t of A -> print $ a t B -> print $ b t submitted by benekastah
[link] [17 comments]
Categories: Incoming News

Roman Cheplyaka: How Haskell handles signals

Planet Haskell - Mon, 07/06/2015 - 2:00pm

How is it possible to write signal handlers in GHC Haskell? After all, the set of system calls allowed inside signal handlers is rather limited. In particular, it is very hard to do memory allocation safely inside a signal handler; one would have to modify global data (and thus not be reentrant), call one of the banned syscalls (brk, sbrk, or mmap), or both.

On the other hand, we know that almost any Haskell code requires memory allocation. So what’s the trick?

The trick is that a Haskell handler is not installed as a true signal handler. Instead, a signal is handled by a carefully crafted RTS function generic_handler (rts/posix/Signals.c). All that function does (assuming the threaded RTS) is write the signal number and the siginfo_t structure describing the signal to a special pipe (called the control pipe, see GHC.Event.Control).

The other end of this pipe is being watched by the timer manager thread (GHC.Event.TimerManager). When awaken by a signal message from the control pipe, it looks up the handler corresponding to the signal number and, in case it’s an action, runs it in a new Haskell thread.

The signal handlers are stored in a global array, signal_handlers (GHC.Conc.Signal). When you install a signal action in Haskell, you put a stable pointer to the action’s code into the array cell corresponding to the signal number, so that the timer thread could look it up later when an actual signal is delivered.

See also https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals.

Categories: Offsite Blogs

Daniel Mlot (duplode): Applicative Archery

Planet Haskell - Mon, 07/06/2015 - 2:00pm

It is widely agreed that the laws of the Applicative class are not pretty to look at.

pure id <*> v = v -- identity pure f <*> pure x = pure (f x) -- homomorphism u <*> pure y = pure ($ y) <*> u -- interchange pure (.) <*> u <*> v <*> w = u <*> (v <*> w) -- composition

Monad laws, in comparison, not only look less odd to begin with but can also be stated in a much more elegant way in terms of Kleisli composition (<=<). Shouldn’t there be an analogous nice presentation for Applicative as well? That became a static question in my mind while I was studying applicative functors many moons ago. After finding surprisingly little commentary on this issue, I decided to try figuring it out by myself. 1

Let’s cast our eye over Applicative:

class Functor t => Applicative t where pure :: a -> t a (<*>) :: t (a -> b) -> t a -> t b

If our inspiration for reformulating Applicative is Kleisli composition, the only sensible plan is to look for a category in which the t (a -> b) functions-in-a-context from the type of (<*>) are the arrows, just like a -> t b functions are arrows in a Kleisli category. Here is one way to state that plan in Haskell terms:

> class Applicative t => Starry t where > idA :: t (a -> a) > (.*) :: t (b -> c) -> t (a -> b) -> t (a -> c) > > infixl 4 .* > -- The Applicative constraint is wishful thinking: > -- When you wish upon a star...

The laws of Starry are the category laws for the t (a -> b) arrows:

idA .* v = v -- left identity u .* idA = u -- right identity u .* v .* w = u .* (v .* w) -- associativity

The question, then, is whether it is possible to reconstruct Applicative and its laws from Starry. The answer is a resounding yes! The proof is in this manuscript, which I have not transcribed here as it is a little too long for a leisurely post like this one 2. The argument is set in motion by establishing that pure is an arrow mapping of a functor from Hask to a Starry category, and that both (<*>) and (.*) are arrow mappings of functors in the opposite direction. That leads to several naturality properties of those functors, from which the Applicative laws can be obtained. Along the way, we also get definitions for the Starry methods in terms of the Applicative ones…

> idA = pure id > u .* v = fmap (.) u <*> v

… and vice-versa:

pure x = fmap (const x) idA u <*> v = fmap ($ ()) (u .* fmap const v)

Also interesting is how the property relating fmap and (<*>)…

fmap f u = pure f <*> u

… now tells us that a Functor results from composing the pure functor with the (<*>) functor. That becomes more transparent if we write it point-free:

fmap = (<*>) . pure

In order to ensure Starry is equivalent to Applicative we still need to prove the converse, that is, obtain the Starry laws from the Applicative laws plus the definitions of idA and (.*) just above. That is not difficult; all it takes is substituting the definitions in the Starry laws and:

  • For left identity, noticing that (id .) = id.

  • For right identity, applying the interchange law and noticing that ($ id) . (.) is id in a better disguise.

  • For associativity, using the laws to move all (.) to the left of the (<*>) and then verifying that the resulting messes of dots in both sides are equivalent.

As a tiny example, here is the Starry instance of Maybe…

instance Starry Maybe where idA = Just id Just g .* Just f = Just (g . f) _ .* _ = Nothing

… and the verification of the laws for it:

-- Left identity: idA .* u = u Just id .* u = u -- u = Nothing Just id .* Nothing = Nothing Nothing = Nothing -- u = Just f Just id .* Just f = Just f Just (id . f) = Just f Just f = Just f -- Right identity: u .* idA = u u .* Just id = u -- u = Nothing Nothing .* Just id = Nothing Nothing = Nothing -- u = Just g Just g .* Just id = Just g Just (g .* id) = Just g Just g = Just g -- Associativity: u .* v .* w = u .* (v .* w) -- If any of u, v and w are Nothing, both sides will be Nothing. Just h .* Just g .* Just f = Just h .* (Just g .* Just f) Just (h . g) .* Just f = Just h .* (Just (g . f)) Just (h . g . f) = Just (h . (g . f)) Just (h . g . f) = Just (h . g . f)

It works just as intended:

GHCi> Just (2*) .* Just (subtract 3) .* Just (*4) <*> Just 5 Just 34 GHCi> Just (2*) .* Nothing .* Just (*4) <*> Just 5 Nothing

I do not think there will be many opportunities to use the Starry methods in practice. We are comfortable enough with applicative style, through which we see most t (a -> b) arrows as intermediates generated on demand, rather than truly meaningful values. Furthermore, the Starry laws are not really easier to prove (though they are certainly easier to remember!). Still, it was an interesting exercise to do, and it eases my mind to know that there is a neat presentation of the Applicative laws that I can relate to.

This post is Literate Haskell, in case you wish to play with Starry in GHCi (here is the raw .lhs file ).

> instance Starry Maybe where > instance Starry [] where > instance Starry ((->) a) where > instance Starry IO where

As for proper implementations in libraries, the closest I found was Data.Semigroupoid.Static, which lives in Edward Kmett’s semigroupoids package. “Static arrows” is the actual technical term for the t (a -> b) arrows. The module provides…

newtype Static f a b = Static { runStatic :: f (a -> b) }

… which uses the definitions shown here for idA and (.*) as id and (.) of its Category instance.

<section class="footnotes">
  1. There is a reasonably well-known alternative formulation of Applicative: the Monoidal class as featured in this post by Edward Z. Yang. While the laws in this formulation are much easier to grasp, Monoidal feels a little alien from the perspective of a Haskeller, as it shifts the focus from function shuffling to tuple shuffling.

  2. Please excuse some oddities in the manuscript, such as off-kilter terminology and weird conventions (e.g. consistently naming arguments in applicative style as w <*> v <*> u rather than u <*> v <*> w in applicative style). The most baffling choice was using id rather than () as the throwaway argument to const. I guess I did that because ($ ()) looks bad in handwriting.

</section> Comment on GitHub (see the full post for a reddit link)

Post licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Categories: Offsite Blogs

Announcing yesod-table

Haskell on Reddit - Mon, 07/06/2015 - 1:33pm
Categories: Incoming News

SPJ's Venn diagram on type-correctness

haskell-cafe - Mon, 07/06/2015 - 12:12pm
Hi all, Sometime in the past, I came across a presentation from SPJ in which he showed a Venn diagram showing "programs that compile" and "programs that are correct". Unfortunately, I cannot remember the exact wording and I'm unable to find the slides/talk on google/youtube. Does anyone remember the exact details of the diagram? Or the title of the talk? Is there still a link to it? Thanks, Mathijs
Categories: Offsite Discussion

The GHC Team: GHC Weekly News - 2015/07/06

Planet Haskell - Mon, 07/06/2015 - 10:25am

Hi *,

Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up to discuss the status of the approaching 7.10.2 release.

7.10.2 status

After quite some delay due to a number of tricky regressions in 7.10.1, 7.10.2 is nearing the finish line. Austin cut release candidate 2 on Friday and so far the only reports of trouble appear to be some validation issues, most of which have already been fixed thanks to Richard Eisenberg.

7.10.2 will include a number of significant bug-fixes. These include,

  • #10521, where overlap of floating point STG registers weren't properly accounted for, resulting in incorrect results in some floating point computations. This was fixed by the amazing Reid Barton.
  • #10534, a type-safety hole enabling a user to write unsafeCoerce with data families and coerce. Fix due to the remarkable Richard Eisenberg.
  • #10538, where some programs would cause the simplifier to emit an empty case, resulting in runtime crashes. Fix due to the industrious Simon Peyton Jones.
  • #10527, where the simplifier would expend a great deal of effort simplifying arguments which were never demanded by the callee.
  • #10414, where a subtle point of the runtime system's black-holing mechanism resulting in hangs on a carefully constructed testcase.
  • #10236, where incorrect DWARF annotations would be generated, resulting in incorrect backtraces. Fixed by Peter Wortmann
  • #7450, where cached free variable information was being unnecessarily dropped by the specialiser, resulting in non-linear compile times for some programs.

See the ​status page for a complete listing of issues fixed in this release.

In the coming days we will being working with FP Complete to test the pre-release against Stackage. While Hackage tends to be too large to build in bulk, the selection of packages represented in Stackage is feasible to build and is likely to catch potential regressions. Hopefully this sort of large-scale validation will become common-place for future releases.

If all goes well, 7.10.2 will mark the end of the 7.10 series. However, there is always the small possibility that a major regression will be found. In this case we will cut a 7.10.3 release which will include a few ​patches which didn't make it into 7.10.2.

Other matters

It has been suggested in #10601 that GHC builds should ship with DWARF symbols for the base libraries and runtime system. While we all want to see this new capability in users' hands, 7.10.2 will, like 7.10.1, not be shipping with debug symbols. GHC HQ will be discussing the feasibility of including debug symbols with 7.12 in the future. In the meantime, we will be adding options to build.mk to make it easier for users to build their own compilers with debug-enabled libraries.

In this week's GHC meeting the effort to port GHC's build system to the Shake? build system briefly came up. Despite the volume of updates on the ​Wiki Simon reports that the project is still moving along. The current state of the Shake-based build system can be found on ​Github.

While debugging #7540 it became clear that there may be trouble lurking in the profiler. Namely when profiling GHC itself lintAnnots is showing up strongly where it logically should not. This was previously addressed in #10007, which was closed after a patch by Simon Marlow was merged. As it appears that this did not fully resolve the issue I'll be looking further into this.

~ Ben

Categories: Offsite Blogs