News aggregator

Brent Yorgey: Blogging again, & some major life events

Planet Haskell - Tue, 03/31/2015 - 12:03pm

It’s been a long time since I’ve written anything here; the blog was on hold while I was finishing my PhD and on the academic job market. Now that things have settled down a bit I plan to get back to blogging.

For starters, here are a few of the major events that have happened in the meantime, that readers of this blog might care about:

  • I successfully defended my PhD dissertation in October, officially graduated in December, and got an actual diploma in the mail a few weeks ago. I’ll be back in Philadelphia for the official graduation ceremony in May.
  • I accepted a tenure-track position at Hendrix College in Conway, Arkansas, and will be moving there this summer.
  • Dan Piponi and I had a paper accepted to MPC 2015. Here’s the github repo, and I plan to post a PDF copy here soon (once I get around to incorporating feedback from the reviewers). I look forward to seeing a bunch of folks (Volk?) in Königswinter this summer; I already have my plane tickets (CIU -> DTW -> AMS -> CGN, it’s a long story).
  • Work on diagrams continues strong (no thanks to me!), and we are aiming for a big new release soon—I will certainly post about that here as well.

Categories: Offsite Blogs

Hackage trustee proposal: Curating the Hackage package collection

libraries list - Tue, 03/31/2015 - 11:33am
Dear Haskell Community, For some time Hackage has contained a user group called "Trustees", . Description: The role of trustees is to help to curate the whole package collection. Trustees have a limited ability to edit package information, for the entire package database (as opposed to package maintainers who have full control over individual packages). Trustees can edit .cabal files, edit other package metadata and upload documentation but they cannot upload new package versions." In short, making sure that packages keep building and filling the gap between unreachable maintainers and package take-overs. Up until now we have been very careful with changes since we haven't had a defined process. Spurred by SPJ and others we have been working on a proposal for how we should operate. You can find the proposal here: We would now like your feedback! Some specific things from the proposal that we'd like yo
Categories: Offsite Discussion

Thoughts on redoing the way we organize code from scratch by replacing Hackage with a "Haskellpedia"?

Haskell on Reddit - Tue, 03/31/2015 - 10:45am

I've posted this in another thread, but I guess it deserves one on its own.

If we think about it, imports are stupid. We take it for granted because that is how things are, but the whole way code is organized today is awkward. Files and filesystems are not necessary at all, and there is a link to "author" and "code" that just shouldn't exist. Haskell allow us to do much better.

My suggestion is a global encyclopedia of symbols (functions/values). Hackage (and imports) must die completely and be replaced by a symbolic linking system that lookups on that wiki of code. That is, for example:

SrPeixinho/PrintOne/main.hsp SrPeixinho.PrintOne.main = IO.print (List.head [1,2,3,4])

By having this file on my system I'm actually defining a symbol on the Global Haskell Encyclopedia. Each file must have only one symbol , which can be backed by QuickCheck laws. If you try to compile this program with GHC, it will complain IO.print and List.head are undefined. If we compile it with "hsp", it will instead lookup into the global repository, find the proper entries:

List.head (x : xs) = x IO.print = ...

download List/head.hs and IO/print.hs to your computer, prepend the proper imports and compile just fine. Of course, this requires that each symbol ever defined has an unique name, but that is cool. "List.head" has a short name because it is so common. If you are programming a different kind of list or something private, you can just append your name to the namespace: YourName.List.head. But, ideally, you would just be clear about the difference and use SnocList.head, so the community can help improving on it. Finally, we can have an using statement, or something similar, to avoid typing full names locally.

This approach would:

  1. Set us free from ever having to look where something you need is, or to ever type import again.

  2. Set us free from spending hours trying organize our codebase in awkward modules that almost always don't express correctly the dependencies of your code.

  3. Promptly amenize considerably the cabal hell problem since, now, an update in a function only affects programs using that function. That is, today, if we have a module with 500 functions, one of which is buggy and barely used, unfortunately fixing that function will cause every library depending on that module to break, even if most don't use that function.

  4. Pave way to a a simple, definite solution of the cabal hell problem: prohibiting that someone makes a change on a global function that breaks its QuickCheck laws. If that is necessary, that person has to instead use a different name and trigger an warning that the old function is deprecated. The only drawback is that we will lose a namespace, but the guarantee that code will never break again is a really, really good tradeof.

  5. Make the process of collaborative coding much easier in general, by following the already established model of Wikipedia, which, IMO, is the most important win this community needs right now.

submitted by SrPeixinho
[link] [25 comments]
Categories: Incoming News

ゆるふわなHaskell話 - Tue, 03/31/2015 - 2:36am
Categories: Offsite Blogs

Literate Haskell rendering on GitHub

Haskell on Reddit - Tue, 03/31/2015 - 1:57am

It used to be the case that GitHub would assume all .lhs files were bird-style Markdown content, and would murder LaTeX-style files. Those days are gone, thankfully, but I do miss rendering for files that are actually Markdown.

I've recently revived the discussion about this, since I think it'd be able to be great for Haskell writers to be able to opt-in to Markdown rendering. The issue, of course, is that it's very hard to detect whether a file is markdown, especially since Literate Haskell doesn't really care. Even if we could relibaly detect LaTeX-style LHS files, which seems easier, we couldn't definitively say whether a bird-style file was intended to be markdown, ReST, or intended to have no markup at all.

If people think it's worth it, I propose to revert the changes in the above pull-request, but with a check that will only render LHS files which contain a certain pragma. Something like

{-# GITHUB markdown #-}

Or even

{-# LITERATE markdown #-}

Or, if a pragma is overkill, maybe a certain style of comment at the top of the file, in the same way that vim detects certain comments in order to apply highlighting.

I think this way would provide the best of both worlds - markup isn't rendered when you don't want it to be, but those authors who use GitHub to host documentation or tutorials can opt-in to nice rendering for free.

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

How to update Mac homebrew formula so that it installs GHC 7.10.1 ?

Haskell on Reddit - Mon, 03/30/2015 - 11:12pm

I use homebrew to install GHC on a Mac. Now that GHC 7.10.1 is out, I'm eagerly waiting for it to show up in the homebrew updates, but it's not there.

Is there someone responsible for updating this homebrew formula?

I'd like to try updating the formula myself but I cannot figure out the homebrew code for GHC. Perhaps someone can point out how this can be done?

submitted by stasiana
[link] [9 comments]
Categories: Incoming News

Semantics of temporal data

haskell-cafe - Mon, 03/30/2015 - 9:23pm
Hello all, I wrote a Temporal datatype data Temporal a = Temporal { td :: a, -- "temporal default" tc :: [Change a] -- "temporal changes" } deriving (Eq, Show) data Change a = Chg { ct :: Time, -- "change time" cv :: a -- "change value" } deriving (Eq,Show) I got into semantic trouble when trying to write "join" for Temporal (Temporal a). If I have a Temporal Temporal, then each change's value is a Temporal. The question is: what significance does the temporal default have? In my implementation, when I look at this Chg t0 (Temporal default0 changes0) Chg t1 (Temporal default1 changes1) --<-- you are here Chg t2 (Temporal default2 changes2) I accept the changes1 which are >= t1 and less than t2. So far so good. But I also take the default1 and prepend it to the resuling list of changes with a change time of t1 (unless the first of the changes1 occurs also at t1). But by comparing results with a handwritten <*>, QuickCheck revealed that this is not in line with <*>
Categories: Offsite Discussion

Parallel Profiling

glasgow-user - Mon, 03/30/2015 - 6:37pm
Does anyone know of any tools for analysing parallel program performance? I am trying to use threadscope but it keeps crashing with my 100M log file and ghc-events-analyze is not going to help as I have many hundreds of threads all carrying out the same computation. I think I’d like a library that would allow me to construct my own analyses rather than display them via GTK. There is ghc-events but that seems to be just for parsing the logs and I couldn’t find anything that used it in the way I would like to (apart from threadscope and ghc-events-analyze of course). Thanks Dominic Steinitz dominic< at >
Categories: Offsite Discussion

GHC 7.10.1 on OS X

haskell-cafe - Mon, 03/30/2015 - 6:32pm
Does anyone know how to resolve this issue? When I do a "cabal build", I get error: unknown directive .macosx_version_min 10, 0 ^ <no location info>: Error running clang! you need clang installed to use theLLVM backend (or GHC tried to execute clang incorrectly) <no location info>: ghc: phase `Clang (Assembler)' failed (exitcode = 1) However, my clang is fine, as is my LLVM: % clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix % opt --version LLVM ( LLVM version 3.5.1 Optimized build with assertions. Built Jan 15 2015 (18:24:46). Default target: x86_64-apple-darwin14.1.0 Host CPU: core-avx2
Categories: Offsite Discussion

Enforcing data structures invariant in the typesystem

haskell-cafe - Mon, 03/30/2015 - 6:00pm
Hi all. I’m very interested in what can be done with Haskell’s type system regarding the enforcing of algorithms and data structures invariants. For example, I remember I saw a paper about an implementation of a red-black tree in Haskell where the types guaranteed the invariant about the alternation of rad and black nodes. I would like to learn those techniques, in particular the use of language features that enable this kind of things and then how to do them in practice. In the past tried hacking something with GADTs and Data Kinds but I've always got stuck with GHC errors that I could not understand, so I think I’m missing something. Where could I start from? Are there simple walk-through examples and/or fundational material? For example is it possible to write a sorting function that guarantees in the types that the output is sorted? I don’t need this specific example but you got the point. Thank you very much, Nicola _______________________________________________ Haskell-Cafe mailing l
Categories: Offsite Discussion

New Functional Programming Job Opportunities

haskell-cafe - Mon, 03/30/2015 - 5:00pm
Here are some functional programming job opportunities that were posted recently: Full-stack Software Engineer at Capital Match Cheers, Sean Murphy
Categories: Offsite Discussion

preprocessing and Parsec

haskell-cafe - Mon, 03/30/2015 - 3:18pm
G'day, I'm implementing a parser for a language that has a preprocessor. It has `include, `ifdef..`else..`endif, `define and uses of the `defined fragments, which are also prefixed by '`'. I can think of two ways of doing this: a preprocess :: Stream->Stream (for String, Text, ByteString) or processing preprocessor directives as part of the"whitespace skipping" at begin of file and after each token. The first one seems cleaner/easier (and also allow parsers not to require a (restricted) IO monad for reading files). The second one, seems to make easier to give nice error messages (in the separate preprocessor way, you can add something like #line to tell where inclusions came from, but you cannot easily do this for macro replacement). My eventual goal is to give clang-like error messages with macro expansion backtrace. Any recommendations? pointers to examples of parsec-based parsers that have a pre-processing step? Thanks, Maurizio _______________________________________________ Haskell-Cafe mailing
Categories: Offsite Discussion