News aggregator

Haskell Weekly News: Issue 309

General haskell list - Thu, 10/09/2014 - 5:07am
Welcome to issue 309 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from September 28 to October 4, 2014 Quotes of the Week * Uh... I'ma have to read the IRC logs... No good quotes < at >remember'd Top Reddit Stories * Announcing needle: ASCII-fied arrow notation Domain:, Score: 103, Comments: 119 Original: [1] On Reddit: [2] * How we might abolish Cabal Hell, part 1 Domain:, Score: 95, Comments: 69 Original: [3] On Reddit: [4] * After some failed attempts to learn Parsec I came across this incredibly patient tutorial and now I'm writing parsers! Domain:, Score: 79, Comments: 17 Original: [5] On Reddit: [6] * Neil Mitchell's Haskell Blog: Why Traversable/Foldable should not be in the Prelu
Categories: Incoming News

Looking for a Google Hangouts tutor/advisor onHaskell

haskell-cafe - Thu, 10/09/2014 - 4:01am
I am looking for a Haskell developer who can review my code, suggest improvements, and generally help me become a better Haskell programmer more quickly. As such, you should be very proficient with Haskell yourself. Maybe you do Haskell work professionally; maybe you have contributed to a couple open-source projects, maybe you're a well-known Haskell blogger, writer or teacher. I am a beginner, although I have been programming professionally for many years. I do have a basic foundation in functional programming languages, including Haskell, but most of my background is with dynamic languages like Ruby and Python. I'm thinking we would meet once a week on a Google Hangout (or other technology) for an hour or so and I'd show you my code and have you review it. (Take it away and mark it up if you want.) I'd ask questions and we can discuss them. You can tell me about anything you think I might need to know to be more effective. I might also email questions to you or ask for more time than described abo
Categories: Offsite Discussion

Philip Wadler: SNAPL

Planet Haskell - Thu, 10/09/2014 - 3:39am

SNAPL will take place 3-6 May 2015 at Asilomar.
SNAPL provides a biennial venue to focus on big-picture questions, long-running research programs, and experience reports in programming languages. The ideal SNAPL paper takes one of two forms:
  • A promising idea that would benefit from discussion and feedback.
  • A paper about an ongoing research project that might not be accepted at a traditional conference.
Examples include papers that
  • lay out a research roadmap
  • summarize experiences
  • present negative results
  • discuss design alternatives
SNAPL is interested in all aspects of programming languages. The PC is broad and open-minded and receptive to interesting ideas that will provoke thought and discussion.
Interesting papers would combine the specific with the general. Submissions are limited to five pages (excluding bibliography), and must be formatted using ACM SIG style. The final papers can be up to 10 pages in length. Accepted papers will be published on an open-access site, probably arXiv CoRR.
To encourage authors to submit only their best work, each person can be an author or co-author of a single paper only. SNAPL will prefer experienced presenters and each submission must indicate on the submission site which co-author will present the paper at the conference.
SNAPL also accepts one-page abstracts. Abstracts will be reviewed lightly and all submitted abstracts will be published on the SNAPL 2015 web page. Authors of selected abstracts will be invited to give a 5-minute presentation at the gong show at the conference.
SNAPL is unaffiliated with any organization. It is a conference for the PL community organized by the PL community.
Important DatesSubmission: January 6, 2015
Decisions announced: February 20, 2015
Final versions due: March 20, 2015
Conference: May 3-6, 2015
Categories: Offsite Blogs

Jop opening: web developers (with a taste forHaskell!) at Anchor

haskell-cafe - Thu, 10/09/2014 - 2:26am
Web Developers and Web Designers ================================ The engineering department at Anchor is building the analytics capabilities, internal systems, cloud infrastructure, deployment tooling, and operations practices that will be needed to take the company to the next level. These things all need front-ends. It goes without saying that the web is the platform for bringing new products to market, but we're a hosting company; most of our staff are operations-focused and our customers are too. What they really want are better tools to manipulate infrastructure. And even though Real Sysadmins™ prefer command-line tools (we build those too) there's still the need to cleanly present and visualize information, and the web is the place to do that. Haskell is the working language for internal development; the benefits of type safety, resilience when refactoring, and stability over time added to the power of functional programming has already paid dividends. An open question is how far we can push s
Categories: Offsite Discussion

type families with non-type indices

haskell-cafe - Wed, 10/08/2014 - 1:28pm
Is there an analog or variant of type families that is indexed by values rather than by types? An example of such a family is integers mod p. One wants to define the operations once for all p, so that a type for any particular p can be introduced by a one-line declaration. Of course this can be done with p being a run-time parameter: data Modp = Modp Integer Int instance Num (Modp) where (Modp x p) + (Modp y q) = if p==q then Modp ((x+y) 'mod' p) p else error "unequal moduli in Modp operation" But it would be better to catch the error at compile time and not have to check at every operation. Doug
Categories: Offsite Discussion

How to represent a list of opaque fingerprint data?

Haskell on Reddit - Wed, 10/08/2014 - 10:26am


I'm currently porting my efforts on finding function addresses in patched binaries in D to Haskell (FWIW, D:, Haskell: I do so by computing fingerprints consisting of certain characteristics for each function, its basic blocks that is.

In order not to have to save the base binary itself, I decided that every characteristic can return some opaque data in its characterize function which can later be accessed when computing the score in matchingScore.

There might be a characterizer counting instructions, where the payload might be an [Int] and another might compute a hash for early detection of unchanged functions. Both payloads are opaque to calling code. Nevertheless they should be handled in a uniform way, e.g. mappable. I figured I could use existential types for that, but it feels just wrong. Obviously, don't take the last two functions too seriously, it's just how I want to call it.

Here is what I got so far:

{-# LANGUAGE ExistentialQuantification #-} type Address = Int data Disassembly = MkDisassembly data Characterizer ch = MkCharacterizer { characterize :: Disassembly -> Address -> ch , matchingScore :: Disassembly -> Address -> ch -> Float } data GenericCharacterizer = forall ch . WrapCharacterizer (Characterizer ch) type Characterizers = [GenericCharacterizer] --computeCharacteristics :: Characterizers -> Disassembly -> Address -> [forall ch . ch] --totalScore :: Characterizers -> Disassembly -> Address -> [forall ch . ch] -> Float

I'm actually looking for design advice: As I see it, there are at least 3 different ways to achieve what I want:

  • Existentials as done here, although the last 2 functions can't function like that yet
  • Data.Dynamic
  • Data.HList.HList (only type safe solution, but also least extensible I think)

I hope I could convey what I mean. How would you design this if you knew that ch will never need to be accessed outside Characterizer functions (except for a possible serialization step later on)?

submitted by sgraf812
[link] [8 comments]
Categories: Incoming News

As a follow-up for my previous question, is this an acceptable way to encode "interferes" in Haskell?

Haskell on Reddit - Wed, 10/08/2014 - 9:36am
import Data.Array {- Hello, I'm trying to figure out how I am supposed to do "inheritance", or interfaces, in Haskell. Many solutions were suggested, but I personally tend to avoid typeclasses, so I've enjoyed this take: -} {- define a common Map interface as a type. -} data Map = Map { get :: Int -> Int, set :: Int -> Int -> Map } {- To implement a particular instance, we use another type... -} data ListMap = ListMap [Int] deriving Show {- And just a function to inject from that type into Map. -} makeMap (ListMap list) = Map { get = (list !!), set = \i x -> makeMap (ListMap (take i list ++ x : drop (i+1) list))} {- So a particular map can be created from a ListMap using makeMap. -} mp = makeMap (ListMap [0,1,4,9,16,25]) {- And it works... -} main = print $ (get mp 2, get (set mp 3 99) 3) {- Questions: 1. Is this linguistic? 2. Will I be yelled at if I do this instead of typeclasses from now on? 3. Is there any problem with this approach, in general, including performance? -} submitted by SrPeixinho
[link] [24 comments]
Categories: Incoming News