News aggregator

Magnus Therning: Thought on JavaScript

Planet Haskell - Tue, 01/13/2015 - 6:00pm

Over the holidays I’ve been reading Douglas Crockford’s excellent book JavaScript: The Good Parts. About halfway through I came to the conclusion that JavaScript is an “anti-LISP”. There are many reasons to learn LISP, but none of them is “LISP is widely used in industry.” As Eric Raymond is famous words claim, knowing LISP will make you a better programmer. On the other hand there seems to be almost no reasons to learn JavaScript. It sure doesn’t seem to teach anything that’ll make you a better programmer. The only reason I can come up with is “JavaScript is widely used in industry.”

Categories: Offsite Blogs

FP Complete is hiring: Software engineer

haskell-cafe - Tue, 01/13/2015 - 4:31pm
Hi list, FP Complete is expanding yet again! We are looking to hire for several new engineers to join our Haskell development team, both to build great new core products and in partnership with our clients to apply Haskell at a large scale. Some of our recently announced core products include the Integrated Analysis Platform, Stackage and LTS Haskell, with much more to come. If you’d like to be part of our team and shape the future of Haskell, please send a resume or CV to jobs+dev< at >fpcomplete.com. Any existing work - either a running website or an open source codebase - which you can include as links be greatly appreciated as well. We will want you to start right away. Depending on your current jurisdiction, this will either be a full-time contractor position, or an employee position. This is a telecommute position: you can work from home or wherever you choose, with little or no travel. Location in North America preferred; but you will work with colleagues who are both on North American and European hou
Categories: Offsite Discussion

ANNOUNCE: picoparsec-0.1

haskell-cafe - Tue, 01/13/2015 - 3:30pm
The newly released package picoparsec [1] is a fork of attoparsec that works with a much wider variety of input types than just ByteString and Text. Parsers written with Picoparsec will generally perform a bit slower than Attoparsec on strict ByteString and Text, somewhat faster than Attoparsec on lazy Text, and much faster than Parsec on any of the mutually-supported input types. That being said, the main point of the library is to enable the writing of generic parsers that are not constrained to any single input type. Depending on the parser primitives used, Picoparsec will take any input whose type is an instance of either NullMonoid, LeftGCDMonoid, FactorialMonoid, or TextualMonoid. These are some of the subclasses of Monoid defined in the monoid-subclasses package [2]. Some of the input types that are fully supported out of the box would be: - Text - String - Seq Char - Vector Char - ByteStringUTF8, a thin newtype wrapper around ByteString - Stateful (Map String a) Text, if you need to parse T
Categories: Offsite Discussion

www.cse.unsw.edu.au

del.icio.us/haskell - Tue, 01/13/2015 - 2:53pm
Categories: Offsite Blogs

working my way through Data.Type.Equality...my headhurts...

haskell-cafe - Tue, 01/13/2015 - 2:39pm
Full code here… https://github.com/goldfirere/nyc-hug-oct2014/blob/master/Equality.hs Lets start at the beginning… Ø data a :~: b where Ø Refl :: a :~: a Looks reasonable….” a :~: b” is inhabited by 1 value…of type “a :~: a” Ø sym :: (a :~: b) -> (b :~: a) Ø sym Refl = Refl hmmm… (a :~: b) implies that a is b so (b :~: a) brilliant Ø -- | Transitivity of equality Ø trans :: (a :~: b) -> (b :~: c) -> (a :~: c) Ø trans Refl Refl = Refl Ø -- | Type-safe cast, using propositional equality Ø castWith :: (a :~: b) -> a -> b Ø castWith Refl x = x fine…. But…. Ø -- | Generalized form of type-safe cast using propositional equality Ø gcastWith :: (a :~: b) -> ((a ~ b) => r) -> r Ø gcastWith Refl x = x I don’t even understand the signature What does “~” mean…(it’s something that comes out in error messages when my types are all messed up)….and then there’s a “=>” going on…in the
Categories: Offsite Discussion

--disable-{executable-}profilingcabal-install-1.22.0.0 with ghc-7.6.3

haskell-cafe - Tue, 01/13/2015 - 2:28pm
A recent change in cabal-install's command line interface seems not to be compatible with ghc-7.6.3. cabal-install-1.22.0.0 doesn't like --disable-executable-profiling as a command line option any more. (I could only find this related to this change: https://github.com/haskell/cabal/pull/2286) $ cabal install --disable-executable-profiling cabal: unrecognized 'install' option `--disable-executable-profiling' I try --disable-profiling instead. $ cabal install transformers --disable-profiling -j3 Resolving dependencies... Notice: installing into a sandbox located at [snip] Configuring transformers-0.4.2.0... Failed to install transformers-0.4.2.0 Build log [snip]: unrecognized 'configure' option `--disable-profiling' cabal: Error: some packages failed to install: transformers-0.4.2.0 failed during the configure step. The exception was: ExitFailure 1 Using the following versions of cabal and ghc. $ cabal -V cabal-install version 1.22.0.0 using version 1.22.0.0 of the Cabal library $ ghc -V The Glorious Gl
Categories: Offsite Discussion

conflicting multi-parameter family instance declarations

glasgow-user - Tue, 01/13/2015 - 2:08pm
Dear all, The following compiles with ghc 7.6 but fails with ghc 7.8: ----- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} module Test where class M t s where type T t s data I t = I t instance M t t where type (T t t) = () instance M t (I t) where type (T t (I t)) = () ----- The error I get with ghc 7.8.3 and 7.8.4 is: Test.hs:12:10: Conflicting family instance declarations: T t t -- Defined at Test.hs:12:10 T t (I t) -- Defined at Test.hs:15:10 I am curious if this change is an improvement or a bug. I would be grateful for help as this issue affects a fairly large library I develop. Best regards, Michal
Categories: Offsite Discussion

What are the benefits of learning Category Theory for a Haskeller?

Haskell on Reddit - Tue, 01/13/2015 - 1:15pm

I have been on the fence about learning Category Theory more than once. On the one hand the promise of a generalized view on many concepts in mathematics seems attractive and I have hopes that it would help me see connections which I would otherwise miss. On the other hand it does seem fairly abstract (duh) and I am not sure what insights related to programming / designing abstractions would result from it.

  1. What benefits have you reaped from learning CT?

  2. I am thinking about working through Awodey's book. What would you suggest (in addition / instead) to maximize the value of CT for a Haskell programmer?

EDIT: I'd like to thank everyone for the answers... certainly some interesting points! I am not fully convinced either way, but in some way I think I'll have to learn it at some point to figure out my answer...

EDIT2: So I've now watched the video recommended by /u/slacket and must say this was quite helpful in answering the question. In the talk Prof. Gibbons hints at how concepts from CT help one to understand folds, unfolds and bifunctors. If this is a preview of things one might be able to understand thanks to CT, then I want to know it! Thanks!

submitted by paulkoer
[link] [10 comments]
Categories: Incoming News

uu-parsinglib - Greedy Parser

haskell-cafe - Tue, 01/13/2015 - 12:57pm
In the uu-parsinglib the choice combinator (<|>) is symmetric and does not commit to any alternative. If the grammar being parsed is ambiguous, the corresponding parser will fail at run time on an ambiguous input. Consider for instance this html parser. pTag = pOpenTag <|> pCloseTag <|> pCommentTag <|> pContent pContent = Content <$> some (satisfy (/= '<')) pHtml = some pTag This parser will fail on "<a>123</a>", because this may be interpreted as: [ [Open a , Content "123", Close a], [Open a, Content "12", Content "3", Close a], [Open a, Content "1", Content "2", Content "3", Close a] ... ] In other parsing libraries such as parsec the choice operator <|> is greedy and commits to the first alternative that makes any progress, so that some is greedy and Content "123" would be parsed. The operator <<|> in uu-parsinglib has the same greedy behaviour. I would like to disambiguate the grammar so that the first result ([Open a, Content "123", Close a]) is selected (longest matching rule). I suppose that
Categories: Offsite Discussion

Neil Mitchell: User Interfaces for Users

Planet Haskell - Tue, 01/13/2015 - 12:56pm

Summary: When designing a user interface, think about the user, and what they want to know. Don't just present the information you know.

As part of my job I've ended up writing a fair amount of user interface code, and feedback from users has given me an appreciation of some common mistakes. Many user interfaces are designed to present information, and one of the key rules is to think about what the user wants to see, not just showing the information you have easily to hand. I was reminded of this rule when I was expecting a parcel. On the morning of Saturday 10/1/2015 I used a track my parcel interface to find:

The interface presents a lot of information, but most of it is interesting to the delivery company, not to me. I have basically one question: when will my parcel arrive. From the interface I can see:

  • The parcel is being shipped with "Express AM" delivery. No link to what that means. Searching leads me to a page saying that guarantees delivery before 1pm on a business day (some places said noon, some said 1pm). That is useful information if I want to enter into a contract with the delivery service, but not when I'm waiting for a parcel. What happens on Saturday? Do they still deliver, just not guarantee the time? Do they wait until the next business day? Do they do either, as they see fit?
  • My parcel has been loaded onto a vehicle. Has the vehicle has left the depot, or is that a separate step? How many further steps are there between loading and delivery? This question is easy to answer after the parcel has been delivered, since the additional steps show up in the list, but difficult to answer before.

On Saturday morning my best guess about when the parcel would arrive was between then and Monday 1pm. Having been through the complete process, I now know the best answer was between some still unknown time on Monday morning and Monday 1pm. With that information, I'd have taken my son to the park rather than keeping him cooped up indoors.

I suggest the company augment their user interface with the line "Your parcel will be delivered on Monday, between 9am and 1pm". It's information they could have computed easily, and answers my question.

The eagle-eyed may notice that there is a plus to expand to show more information. Alas, all that shows is:

I think they're trying to say my puny iPhone can't cope with the bold font that is essential to tell me the status and I should get an iPhone plus... Checking the desktop website also showed no further information.

Categories: Offsite Blogs

Avoid blank line separating code and comments in Bird style?

glasgow-user - Tue, 01/13/2015 - 12:28pm
Hi This regarding GHC behaviour for literate Haskell programs in Bird style. GHC expects a blank line between comment[1] and code. Otherwise, during the literate pre-processor stage, the error 'unlit: Program line next to comment' is reported. While above behaviour makes sense in general, there are situations where one would like to place comments adjacent to code with no intervening blank line. For example, in documenting a declaration using Haddock (in standard, non-literate Haskell), as shown in sections 3.1 <https://www.haskell.org/haddock/doc/html/markup.html#idm140354810917952> and 3.2 <http://www.haskell.org/haddock/doc/html/ch03s02.html> of the Haddock User Guide, no blank line separates comment and code. Any way to enable GHC to accept Bird style literate programs with no blank lines separating comment and code? [1] 'Comment' (in context of Bird style) refers to text on lines not beginning with '>'. Regards Sidhu _______________________________________________ Glasgow-haskell-users mailing list
Categories: Offsite Discussion

Is Data.Ratio widely used/ a good idea ?

Haskell on Reddit - Tue, 01/13/2015 - 12:06pm

I need basic calculation (on prices and quantity), and for some reasons I don't like float or double (mainly rounding errors), so I'm thinking of using Ratio (or Decimal ?) instead. Is it something widely used or at the contrary that I should avoid (and if so, why ?)

submitted by maxigit
[link] [18 comments]
Categories: Incoming News

Vacancies: 4 PhD students Software Technology UtrechtUniversity

General haskell list - Tue, 01/13/2015 - 11:26am
============================================================ 4 x PhD position in Software Technology ============================================================ The research group of Software Technology is part of the Software Systems division of in the department of Information and Computer Science at the Utrecht University. We focus our research on functional programming, compiler construction, program analysis, validation, and verification. Financed by the Netherlands Organisation for Scientific Research (NWO), the EU, Technology Foundation STW and Utrecht University we currently have job openings for four PhD researchers (PhD students) in Software Technology. We are looking for PhD students to work on some of the following topics: * Version control of structured data The theory and practice underlying structure-aware version control systems capable of handling more than just text files. * Intelligent tutoring technologies Technologies for tutoring subjects such as functional programming, st
Categories: Incoming News

Vacancies: 4 PhD students Software TechnologyUtrecht University

haskell-cafe - Tue, 01/13/2015 - 11:26am
============================================================ 4 x PhD position in Software Technology ============================================================ The research group of Software Technology is part of the Software Systems division of in the department of Information and Computer Science at the Utrecht University. We focus our research on functional programming, compiler construction, program analysis, validation, and verification. Financed by the Netherlands Organisation for Scientific Research (NWO), the EU, Technology Foundation STW and Utrecht University we currently have job openings for four PhD researchers (PhD students) in Software Technology. We are looking for PhD students to work on some of the following topics: * Version control of structured data The theory and practice underlying structure-aware version control systems capable of handling more than just text files. * Intelligent tutoring technologies Technologies for tutoring subjects such as functional programming, st
Categories: Offsite Discussion