News aggregator

Well-Typed.Com: Haskell development jobs with Well-Typed

Planet Haskell - Tue, 03/08/2016 - 10:24am

tl;dr If you’d like a job with us, send your application as soon as possible.

We are looking for several (probably two) Haskell experts to join our team at Well-Typed. This is a great opportunity for someone who is passionate about Haskell and who is keen to improve and promote Haskell in a professional context.

About Well-Typed

We are a team of top notch Haskell experts. Founded in 2008, we were the first company dedicated to promoting the mainstream commercial use of Haskell. To achieve this aim, we help companies that are using or moving to Haskell by providing a range of services including consulting, development, training, and support and improvement of the Haskell development tools. We work with a wide range of clients, from tiny startups to well-known multinationals. We have established a track record of technical excellence and satisfied customers.

Our company has a strong engineering culture. All our managers and decision makers are themselves Haskell developers. Most of us have an academic background and we are not afraid to apply proper computer science to customers’ problems, particularly the fruits of FP and PL research.

We are a self-funded company so we are not beholden to external investors and can concentrate on the interests of our clients, our staff and the Haskell community.

About the jobs

One of the roles is for a specific project with one of our clients, and requires work on-site in London. The other role is more general and not tied to a single specific project or task, and allows remote work.

Please indicate in your application whether on-site work in London is an option for you.

In general, work for Well-Typed could cover any of the projects and activities that we are involved in as a company. The work may involve:

  • working on GHC, libraries and tools;

  • Haskell application development;

  • working directly with clients to solve their problems;

  • teaching Haskell and developing training materials.

We try wherever possible to arrange tasks within our team to suit peoples’ preferences and to rotate to provide variety and interest.

Well-Typed has a variety of clients. For some we do proprietary Haskell development and consulting. For others, much of the work involves open-source development and cooperating with the rest of the Haskell community: the commercial, open-source and academic users.

Our ideal candidate has excellent knowledge of Haskell, whether from industry, academia or personal interest. Familiarity with other languages, low-level programming and good software engineering practices are also useful. Good organisation and ability to manage your own time and reliably meet deadlines is important. You should also have good communication skills. Being interested or having experience in teaching Haskell (or other technical topics) is a bonus. Experience of consulting or running a business is also a bonus. You are likely to have a bachelor’s degree or higher in computer science or a related field, although this isn’t a requirement.

Offer details

The offer is initially for one year full time, with the intention of a long term arrangement. For the remote role, living in England is not required. For the on-site role, you have to be allowed to work in England. We may be able to offer either employment or sub-contracting, depending on the jurisdiction in which you live.

If you are interested, please apply via info@well-typed.com. Tell us why you are interested and why you would be a good fit for Well-Typed, and attach your CV. Please indicate whether the on-site work in London is an option for you. Please also indicate how soon you might be able to start.

We are more than happy to answer informal enquiries. Contact Duncan Coutts (duncan@well-typed.com, dcoutts on IRC), Adam Gundry (adam@well-typed.com, agundry on IRC) or Andres Löh (andres@well-typed.com, kosmikus on IRC) for further information.

We will consider applications as soon as we receive them, and will try to fill the positions as soon as possible. In any case, please try to get your application to us by March 27, 2016.

Categories: Offsite Blogs

Use cases of empty type classes

haskell-cafe - Tue, 03/08/2016 - 8:10am
Hi everyone, I have one question. What are current use cases of type classes with no methods? I saw early uses in type-level programming (e.g. HList [1]). In the OO world, interfaces with no methods are called marker interfaces -- their use cases range from things that could be done with datatype generic programming in Haskell (e.g. serialization) to metadata annotations (e.g. RandomAccess [2]). Regards, Tomas Tauber [1] http://okmij.org/ftp/Haskell/HList-ext.pdf [2] https://docs.oracle.com/javase/8/docs/api/java/util/RandomAccess.html
Categories: Offsite Discussion

Add `take`/`drop`/`splitAt` to `Data.Map`/`Data.Set`

libraries list - Tue, 03/08/2016 - 2:14am
I would like to propose adding `take`/`drop`/`splitAt` to both `Data.Map` and `Data.Set` as originally requested in: https://github.com/haskell/containers/issues/135 <https://github.com/haskell/containers/issues/135> The motivation behind this proposal is three-fold: * for convenience - these functions are commonly used to implement pagination or previews of maps/sets * for type accuracy - the public API impose an unnecessary `Ord` constraint * for efficiency - these can be implemented more efficiently using the internal API Currently the only way you can implement this functionality via the public API is to use `lookupIndex`/`elemAt` + `split`. For example, one way to implement `Data.Set.take` is: take :: Ord a => Int -> Set a -> Set a take n m | n < 0 = empty | size m <= n = m | otherwise = lt where (lt, _) = split k m k = elemAt n m {-# INLINE take #-} This implementation incurs an unnecessary `Ord` constraint due to a roundabout way of computing `take`: this ext
Categories: Offsite Discussion

implicit call stacks and calling function

haskell-cafe - Mon, 03/07/2016 - 9:35pm
I noticed this when I started using the new implicit call stacks feature. I didn't bring it up because I figure it probably had a good reason and was too late to change anyway, but the recent talk about HasCallStack reminded me and I'm curious. When you do GHC.Stack.getCallStack you get a [(String, SrcPos)]. The SrcPos is the position of the calling function, but the String is the callee function. So you can't get the name of the calling function. Instead, you get the name of the function with the call stack annotation. That's not so useful because in say a logging function, I'm interested in the caller's name. I don't need the name of the logging function, it's just something boring like "info" or "warn"! When I switched from a custom preprocessor that sort of implemented SRCLOC_ANNOTATE, it was definitely nice to lose the custom local hackery, but not so nice to lose the caller's name. For tests I used an unsafe mutable global via unsafePerformIO, otherwise failed tests can't report the name of the
Categories: Offsite Discussion

[ANN] brick-users discussion list

General haskell list - Mon, 03/07/2016 - 7:56pm
Hi, If you use the 'brick' library then you might like to know that there is now a library discussion list for it: https://groups.google.com/d/forum/brick-users
Categories: Incoming News

Magnus Therning: Final version of JSON to sum type

Planet Haskell - Mon, 03/07/2016 - 6:00pm

After some feedback on my previous post I ended up with the following implementation.

instance FromJSON V.VersionRange where parseJSON = withObject "VersionRange" go where go o = V.thisVersion <$> o .: "ThisVersion" <|> V.laterVersion <$> o .: "LaterVersion" <|> V.earlierVersion <$> o .: "EarlierVersion" <|> V.WildcardVersion <$> o .: "WildcardVersion" <|> nullaryOp V.anyVersion <$> o .: "AnyVersion" <|> binaryOp V.unionVersionRanges <$> o .: "UnionVersionRanges" <|> binaryOp V.intersectVersionRanges <$> o .: "IntersectVersionRanges" <|> V.VersionRangeParens <$> o .: "VersionRangeParens" nullaryOp :: a -> Value -> a nullaryOp = const binaryOp f [a, b] = f a b

Thanks David for your suggestions.

Categories: Offsite Blogs

Tagged instances for Aeson overlapped

haskell-cafe - Mon, 03/07/2016 - 4:37pm
Hello, I tried to compile my project with GHC 8 (from HEAD). And I got One of instances should be removed probably. I suppose that instance for removing should be instance in Data.Tagged. But version in Aeson should be PolyKinded. What do you think? Best regards, Dmitry _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Trouble on Travis CI with recent cabal versions

haskell-cafe - Mon, 03/07/2016 - 10:19am
For my OpenGLRaw project, I'm using a .travis.yml generated by Herbert's https://github.com/hvr/multi-ghc-travis and the corresponding https://launchpad.net/~hvr/+archive/ubuntu/ghc PPA. Recently things broke on Travis CI, and there are a few strange things: * The cabal-install-head package seems to be based on cabal 1.23, which is older than cabal-install-1.24. Is this intended? * The OpenGLRaw package has no test suite, and this seems to be OK for cabal-install-head ( https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/114109605#L929), while cabal-install-1.24 fails in the "cabal test" step ( https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/114109606#L1022). This is a regression: I think that "cabal test" for a package without a test suite should be a no-op, at least that used to be the case. * Why does "cabal test" say "Re-configuring with test suites enabled. If this fails, please run configure manually." when "cabal configure" has already been run (including --enable-tests)? This looks li
Categories: Offsite Discussion

1-to-many preprocessor in stack/Cabal builds

haskell-cafe - Mon, 03/07/2016 - 8:53am
Hi, I'm writing a package which uses custom preprocessor for creating some of the source files. It takes one IDL file as input and writes several .hs modules, depending on IDL contents. I need to compile this modules with a few normal ones and link them as a library, preferably with generated modules exposed. It doesn't look like a complex task and never was in with make/etc, but I run into some problems now. Obviously, cabal supports 1-to-1 preprocessors to create one Haskell module from one source file (alex, happy, etc), but I can't find anything for 1-to-many preprocessors. So, I decided to use hookedPrograms and hooks and do it myself. The call to preprocessor in the postConf hook worked just fine and created source files and module list. Cabal pre-* hooks seems to be right place to read this module list and use it, but are presenting two problems: can only modify other-modules, not exposed-modules, which is tolerable, and there is no access to build configuration. The latter is fatal, I need to know
Categories: Offsite Discussion

Test email

libraries list - Thu, 03/03/2016 - 7:54pm
Please disregard -- sorry for the noise. Gershom
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News