News aggregator

The Problem with Curation

Haskell on Reddit - Wed, 06/03/2015 - 11:43am
Categories: Incoming News

Haskell source-browsing nirvana?

Haskell on Reddit - Wed, 06/03/2015 - 11:37am

I'm using an awkward mix of hasktags, dash and hoogle. I wonder if anyone has achieved my dream in any editor: It would work like hasktags except it could use context like imports and qualifications to find the correct definition, jumping across the project source into sources for installed packages including ghc base.

submitted by rdfox
[link] [6 comments]
Categories: Incoming News

The Problem with Curation

Haskell on Reddit - Wed, 06/03/2015 - 11:36am
Categories: Incoming News

Haskell dev role in Strats at Standard Chartered(Singapore)

General haskell list - Wed, 06/03/2015 - 9:50am
I have an open position for a Haskell developer to join Standard Chartered's Strats team in Singapore. More details at: https://donsbot.wordpress.com/2015/06/03/haskell-dev-role-in-strats-at-standard-chartered-singapore/
Categories: Incoming News

Pixel by pixel image processing

haskell-cafe - Wed, 06/03/2015 - 8:19am
Hi cafe! I want to do some trivial masking manipulation on PNG images: take a picture, crop it to square shape and then make a circular mask, i.e. take all pixels that lies outside circle with radius equal to half of image width and placed at image center and replace that pixels with zero opacity once (hope this description is clear enough). I've found two packages for image processing so far: `friday` [1] and `unm-hip` [2], but can't figure out which of them suits my needs, maybe there are some other packages I miss? [1] https://hackage.haskell.org/package/friday [2] https://hackage.haskell.org/package/unm-hip _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

-prof, -threaded, and -N

glasgow-user - Wed, 06/03/2015 - 6:20am
Hi, The behavior of the -N flag (without argument) with the profiling runtime seems inconsistent compared to the behavior without profiling. The following program ``` module Main where import GHC.Conc main :: IO () main = print numCapabilities ``` when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof +RTS -N` prints `2` on my machine. When the same program is compiled with `ghc -threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N` it prints `1`. When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling and non-profiling versions behave the same. I tested this with GHC-7.10.1 but I think that I already observed the same behavior with GHC-7.8. Is this inconsistency intended? Lars
Categories: Offsite Discussion

Don Stewart (dons): Haskell dev role in Strats at Standard Chartered [Singapore]

Planet Haskell - Wed, 06/03/2015 - 2:40am

The Strats team at Standard Chartered has an open position for a typed functional programming developer, based in Singapore.

You will work on the trading floor, directly with traders, building software to automate their work and improve their efficiency. The role is highly development focused and you will use Haskell for almost all tasks: data analysis, market data publishing, database access, web services, desktop GUIs, large parallel tasks, quantitative models, solvers, everything. This is a fast paced role – code you write today will be deployed within hours to hundreds of users and has to work.

This is a permanent position in Singapore as part of the Strats global team. Demonstrated experience in typed FP (Haskell, OCaml, F# etc) is required. We have around 2.5 million lines of Haskell, and our own Haskell compiler. In this context we look for skill and taste in typed functional programming to capture and abstract over complex, messy systems.

Experience writing typed APIs to external systems such as databases, web services, pub/sub platforms is very desirable. We like working code, so if you have Hackage or github libraries, we definitely want to see them. We also like StackOverflow answers, blog posts, academic papers, or other arenas where you can show broad FP ability. A PhD in computer science is a strong advantage.

The role requires physical presence on the trading floor in Singapore. Remote work is not an option. Ideally you have some project and client management skills — you will talk to users, understand their problems and then implement and deliver what they really need. No financial background is required.

More info about our development process is in the 2012 PADL keynote, and a 2013 HaskellCast interview.

If this sounds exciting to you, please send your resume to me – donald.stewart <at> sc.com.

Role posted 2015-06-03


Tagged: jobs
Categories: Offsite Blogs

ghc 7.10.1 hard lock on exit with shake, OS X 10.10

glasgow-user - Wed, 06/03/2015 - 2:36am
After I upgraded to 7.10.1 I started noticing that my shakefile would lock up on exit. It's after the 'main' function exits, and none of the shake tests have a problem, so presumably it's a GHC thing, that shake somehow causes to happen. Only kill -9 gets it to quit. Here's a stack trace from the OS X sampler: Call graph: 2801 Thread_909901 DispatchQueue_2: com.apple.libdispatch-manager (serial) 2801 _dispatch_mgr_thread (in libdispatch.dylib) + 52 [0x7fff8828ca6a] 2801 kevent64 (in libsystem_kernel.dylib) + 10 [0x7fff90ec0232] Total number in stack (recursive counted multiple, when >=5): Sort by top of stack, same collapsed (when >= 5): kevent64 (in libsystem_kernel.dylib) 2801 I know there aren't a lot of details here, but does this sound familiar to anyone? I can't see anything on https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 that looks like this. Is there any way I can get more information I can get to report this? It used to be frequent (once
Categories: Offsite Discussion

GHC Weekly News - 2015/06/03

Haskell on Reddit - Wed, 06/03/2015 - 2:32am
Categories: Incoming News

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

Planet Haskell - Wed, 06/03/2015 - 1:03am

Hi *,

It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there.

The main point of discussion was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts!

7.10.2 status

7.10.2 is swimming along very nicely - the ​status page shows the current set of tickets we've fixed and plan on fixing.

Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate.

List chatter
  • Facundo Dominguez asks: sometimes we want to create a static pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html
Noteworthy commits Closed tickets

#10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474,

Categories: Offsite Blogs

HEADS UP: Final call for 7.10.2 is soon

glasgow-user - Tue, 06/02/2015 - 10:31pm
Hi *, I've just finished merging all the latest patches for GHC 7.10.2 into the STABLE branch. All in all, we've fixed a lot of bugs (over 80 tickets closed)! So, we'll probably be doing a 7.10.2 release here in a few weeks. The tentative plan was around the 14th, although it's not set in stone. (At worst, it would be pushed from the 14th to the 21st). With that in mind, if I could quickly direct your attention to the GHC bug tracker and the status page[1] - it would be really helpful if you check if the things you want are fixed! Specifically, if you want something fixed for the 7.10.2 release: - Make sure there is a ticket. It really needs to exist or we'll just forget! - If your bug is critical, please explain why! We really want to kill showstoppers ASAP, because bugs are much cheaper to fix early. If that's the case we can bump the priority if it's necessary to make things clear. - Set the milestone to 7.10.2. It'll automatically appear on the status page. That should be it - we'll be moni
Categories: Offsite Discussion

Four Designs for a Monad

haskell-cafe - Tue, 06/02/2015 - 8:39pm
I'm working on writing a Haskell wrapper for the GNU Lightning code generation library (http://www.gnu.org/software/lightning/), which in C consists of a series of macros that write to a certain global state in a pointer _jit, such as jit_add or jit_call. Now, I figure that can be wrapped fairly simply in a monad, which we'll call the Lightning monad:
Categories: Offsite Discussion

Magnus Therning: Re. cryptonite

Planet Haskell - Tue, 06/02/2015 - 6:00pm

Excellent work Vincent, but then you’ve never done anything but! I’m looking forward to purging all the old crypto packages from ArchHaskell in the near future.

Oh, BTW, why Disqus for comments?

Categories: Offsite Blogs

Ambiguity check and type families

glasgow-user - Tue, 06/02/2015 - 5:28pm
Hi, the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1: GHC 7.10.1 reports: At a first look, this complaint seems reasonable, and I have already wondered why GHC 7.8.3 actually accepts the above code. From an intuitive standpoint, however, the code seems actually acceptable to me. While it is true that type families are generally not injective, it is possible to derive the type a from F a by applying G. It would great if this code would be accepted by GHC again and if there was a workaround to make it work with GHC 7.10.1. At the moment, this change in the type checker from 7.8.3 to 7.10.1 breaks the incremental-computing package in a rather fundamental way. All the best, Wolfgang _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Noam Lewis: infernu news

Planet Haskell - Tue, 06/02/2015 - 4:26pm

In the past month, most of the work on infernu was to stabilize the type system, making decisions about some trade-offs. Here’s a short summary:

  • Colors! I refactored all the pretty printing code to use the ansi-wl-pprint package, which fixes indentation and formatting issues and also adds ansi colors to the output. One neat thing is that identical type variables have the same color:
  • Changed the way constructor functions are treated. Until now, constructor functions were treated at definition site as regular functions. The difference between constructors and non-constructors only happened at “new” calls, where the expected “this” value was forced to be a closed row type. Unfortunately this breaks if you call “new Foo()” inside the definition of “Foo”.
    To avoid this issue, functions with uppercase names are now treated specially and the “this” row-type is forced to be closed when the function name is added to the environment. This allows maximum flexibility while defining Foo, while ensuring Foo’s type is closed outside the constructor to prevent junk code like var x = new Foo(); x.myWrongProperty = 2;
  • Explored the idea of “Maybe” (or “optional”) types, including having common JS APIs use them for stronger safety. For example, array access should return a Maybe value.
    Unfortunately, since there is no syntax to construct a Maybe-typed value (no “Just”), all values can be implicitly “upgradeed” to Maybe. In other words, there is an ambiguity that break type inference. So for now, not implementing Maybe types (perhaps with explicit annotations they can come back).
  • Decided to disable generalization of row fields (object properties). This decision means that user-defined objects will by default not have polymorphic methods, although the object itself could be polymorphic (and thus different occurrences of the object in the program syntax, will allow instantiation to different types). The reason for this decision is that overly-polymorphic fields cause unexpected type errors, such as when passing objects that contain them as parameters to functions (contravariance can surprise you).
  • Started a document sketching out denotational semantics of JS, as infernu decides these should be, which helped clarify a few issues in the JS -> LC translator. The next step is to change all translations to preserve semantics, currently they only preserve types.
  • Bug fixes: polymorphic subsumption checking, unification of recursive types.
  • Increased compatibility: now using base-compat and a custom prelude to increase compatibility with different GHC versions (thanks to RyanGlScott for submitting a fix to use base-orphans which prompted me to do this).

Tagged: Infernu
Categories: Offsite Blogs

Noam Lewis: A simple problem with recursive types and subtyping

Planet Haskell - Tue, 06/02/2015 - 3:56pm

Here’s a simple example of recursive types interacting badly with subtyping:

T={ foo: T -> A}
U={ foo: U -> B}

Consider T <: U, therefore

(T -> A) <: (U -> B)

Which implies:

U <: T

So T <: U but also U <: T, which is true iff A <: B and B <: A.

In my case, the subtyping relation is polymorphic subsumption: T is subsumed by U iff U is “more polymorphic”, intuitively, it can be instantiated to all types that T can.

This situation arises in rather simple code, involving polymorphic vs. non-polymorphic row fields. For example, A is a row with a polymorphic method, whereas B is a row with a monomorphic (but compatible) method, such as:

A = { method: forall a. a -> () }
B = { method: String -> () }

In this case subsumption (the form of subtyping in play) fails.

One way around this is to avoid subsumption issues altogether by keeping things rank-1, and not using higher-rank row fields. Unfortunately, throwing away polymorphic methods is very bad: consider a non-polymorphic array.map (in JS).

A slightly better workaround is to push the foralls all the way out, keeping all types (including row types) rank-1. Every time an object method is accessed via the property syntax obj.method, we end up instantiating the object’s row type, and get a “fresh” type for the method. We get practically polymorphic methods. That’s the approach I’m investigating for infernu.


Tagged: Infernu
Categories: Offsite Blogs

Announcing cryptonite

Haskell on Reddit - Tue, 06/02/2015 - 2:44pm
Categories: Incoming News