News aggregator

How do parametricity and type classes interact?

Haskell on Reddit - Thu, 08/07/2014 - 11:43pm

I've heard responses that they do not interact since type classes are ad-hoc and parametricity requires parametric polymorphism as the name indicates.

But in Wadler's paper Theorems for Free! he gives examples of some theorems (given a : A → A′ and b : B → B′):

sort : ∀X. (X → X → Bool) → [X] → [X] if for all x, y ∈ A, (x < y) = (a x <′ a y) then map a ∘ sort (<) = sort (<′) ∘ map a fold : ∀X. ∀Y. (X → Y → Y) → Y → [X] → Y if for all x ∈ A, y ∈ B, b (x ⊕ y) = (a x) ⊛ (b y) and b u = u′ then b ∘ fold (⊕) u = fold (⊛) u′ ∘ map a

sort corresponds to Haskell's Data.List.sortBy but you could also view both of those parametrically polymorphic functions as ad-hoc functions whose type constraints (Ord and Foldable) have been reified into arguments. So is it valid to view ad-hoc polymorphic functions such as \x -> x == x with type Eq a => a -> Bool as having the following parametric type (a -> a -> Bool) -> a -> Bool (ignoring (/=))?

submitted by haskellthrowaway
[link] [11 comments]
Categories: Incoming News

Looking for name of a concept (relating to parametricity)

Haskell on Reddit - Thu, 08/07/2014 - 11:27pm

Given a function of the following type:

f :: [a] -> [a]

Due to parametricity, the only information f has to make choices is the length of its input list since that is the only “element-independent “information content” of a list”.

Is there a name for this information, the information content you can retrieve from a data type when one or more of its types are parametrically polymorphic.

submitted by haskellthrowaway
[link] [16 comments]
Categories: Incoming News

How does Accelerate performance compare to handwritten OpenCL/CUDA?

Haskell on Reddit - Thu, 08/07/2014 - 10:57pm

I guess it would be much slower, or else why would anyone use CUDA. But has anyone benchmarked it? How does it compare?

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

[ANN] rtorrent-state 0.1.0.0

haskell-cafe - Thu, 08/07/2014 - 8:07pm
Hi, rtorrent-state is a library that allows working with rtorrent state files (SOMEHASH.torrent.rtorrent) placed in your session directory. If you're an rtorrent user and ever had to manually muck around with those files, you should be able to use this library to make your life easier. For example, you can stop all torrents in your session directory with just: “overFilesIn "rtorrent/session/dir" stopTorrent” The way it works is by parsing the session files, modifying the resulting data type and serialising it back into the file. I did not do optimisation but I had no problem with test sample of 100,000 files. I need to add IOException handling and maybe extra utility functions but otherwise I consider the library finished. Thanks
Categories: Offsite Discussion

Haskell is a medium-sized dog

Haskell on Reddit - Thu, 08/07/2014 - 7:18pm
Categories: Incoming News

Performance of StateT and best practices fordebugging

haskell-cafe - Thu, 08/07/2014 - 6:57pm
Hello, I was looking at cleaning up my refactoring a core loop of template rendering to go from a loop with many parameters loop :: RenderConfig -> BlockMap -> InputBucket m -> Builder -> [Pieces] -> ExceptT StrapError m Builder to a looped state monad transformer loop :: [Pieces] -> RenderT m Builder newtype RenderT m a = RenderT { runRenderT :: ExceptT StrapError (StateT (RenderState m) m) a } deriving ( Functor, Applicative, Monad, MonadIO ) data RenderState m = RenderState { position :: SourcePos , renderConfig :: RenderConfig , blocks :: BlockMap , bucket :: InputBucket m } however, there is a big slow down (about 6-10x) using a StateT. I think it might have something to do with laziness but I am not exactly sure of where to begin in tracking it down. Swapping out the Lazy State to a Strict State helps a little (only a 5x slow down) You can find some of the processing code here: https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0
Categories: Offsite Discussion

parsec: problem combining lookAhead with many1 (bug?)

haskell-cafe - Thu, 08/07/2014 - 3:25pm
Suppose that we have the following parser: p = lookAhead (char 'a') >> char 'b' If we use it like so parse p "" "a" we get the following error: Left (line 1, column 1): unexpected "a" expecting "b" What happened is that char 'a' succeeded by consuming the 'a' from the input and then lookAhead rewinded the input stream (as it does on success). Then, char 'b' tries to parse (again) the first character of the input and fails. Everything works as expected. Now let's slightly modify our parser: p' = lookAhead (many1 $ char 'a') >> char 'b' I've only added a many1. I was expecting this parser to give the same error as the previous one: many1 $ char 'a' will succeed consuming one 'a' and then lookAhead will rewind the input (as it does on success). Thus when we call char 'b' we are going to be in the beginning of the input again. Well, that doesn't happen: Left (line 1, column 2): unexpected end of input expecting "b" As you can see, lookAhead did not rewind the input as it was supposed to.
Categories: Offsite Discussion

Free monad based EDSL for writing LLVM programs.

haskell-cafe - Thu, 08/07/2014 - 3:16pm
Hello. I'm new with Haskell and FP, so i wanted someone to give comments on the package i've made [1]. It's, actually, my first attempt to create something more or less real, so any feedback would be welcome. I've used Free monad to create EDSL that allows writing LLVM IR code. Afterwards it could be converted into pure AST structure provided by llvm-general-pure[2] package. Currently, it supports almost every instruction, but i haven't yet come up with sensible defaults for them. Another thing that bugs me is the ability to transform the code in syb way. I want take a user-supplied function that would pattern-match instruction and produce another code block and apply this function everywhere in the code, but still can't get my head around it. I've come up with extF function, that unlike extM, would resort to wrap instead of return, but that's all i've managed to do. Thanks in advance. [1] https://bitbucket.org/arrowdodger/llvm-general-edsl [2] http://hackage.haskell.org/package/llvm-general-pure _______
Categories: Offsite Discussion

Going from intermediate to advanced haskell programming?

Haskell on Reddit - Thu, 08/07/2014 - 11:08am

Hello /r/haskell,

I've been learning Haskell for about 3 months now. I just realized I've written about 11k lines of code so far. I've been reading LYAH, RWH and consult the Haskell Wiki from time to time and Hoogle very often. I'm fairly comfortable with concepts like monads, function composition, type classes, eta reductions and haskell syntax in general.

The problem is most of the code I've written so far are reproductions of projects I've found online e.g. an implementation of the raft protocol in Haskell, a ray tracer in Haskell, a Lisp interpreter in haskell, and numerous other small projects. What I usually do is read through a textual description of the project's source if available (e.g. RWH) and then try to reproduce the code on my own. What I try to understand mainly from these projects is not the exact code that was used but the design thinking that was followed (e.g. which monads to use, what kind of function abstraction helps e.g. where can I return functions for greater effect etc). I only look at the actual code as a fallback if I ever encounter something I don't know how to do in Haskell. So this has been my learning technique so far.

I'm having a hard time figuring out how to progress to the next level of Haskell fluency. I feel like I haven't yet imbibed the Haskell nature of things (when it becomes completely natural to program in a given language). In addition, I've chanced upon numerous discussions here and on other sites/mailing lists (and some code) where I feel completely lost. For instance, there are (just off the top of my head)

  • programming-related things I have:

no idea about: many pragmas -- INLINE/SPECIALIZE/RankNTypes etc, GHC optimization tricks , profiling and performance tuning etc etc.

some idea about: overlapping and incoherent instances, continuations, monomorphisms etc etc.

  • theoretical things I have no idea about: category theory, kleisli arrows, comonads etc etc

Now some might say you don't need to know every feature of a language. No one does. This is true. However, I don't want to miss out on features of the language that can actually make me more productive. For instance, the first time I came across arrows was when hlint suggested using arrows for a certain piece of code. They were actually useful (as opposed to gimmicks learnt only to show off your skillz).

Others might say if you know what you don't know, just get to know it. This is true and all of the things I don't know that I mentioned above, I'm already reading up on.

My question is what is the most effective way to ramp up your Haskell skills to the next level? How did you do it? With a language like Java/C++, there are resources like Effective Java/C++ or tons of advanced programming tutorials online. What is the Haskell equivalent?

TL;DR: title of this post

EDIT: thank you all for your replies and links. I'll keep checking back until this thread dies down.

submitted by don-to-koi
[link] [20 comments]
Categories: Incoming News

Haskell Chart Parser

Haskell on Reddit - Thu, 08/07/2014 - 8:38am
Categories: Incoming News

Haskell Weekly News: Issue 301

haskell-cafe - Thu, 08/07/2014 - 5:43am
Welcome to issue 301 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from July 27 to August 2, 2014 Quotes of the Week * bernalex: I used to have a problem then I used lens now I have an abstraction problem? * trap_exit: haskell is like the 'and they lived happily ever after' of programming languages Top Reddit Stories * The Comonad.Reader » Letter to a Young Haskell Enthusiast Domain: comonad.com, Score: 236, Comments: 56 Original: [1] http://goo.gl/Z5usp3 On Reddit: [2] http://goo.gl/CpPKnC * seL4 is now open source: the world's first end-to-end verified OS kernel Domain: github.com, Score: 87, Comments: 20 Original: [3] http://goo.gl/Uz50bj On Reddit: [4] http://goo.gl/EQK0MQ * FP Haskell Center now free for open projects Domain: fpcomplete.com, Score: 81, Comments: 23 Original: [5] http://goo.gl/ULc9ze On Reddit: [6] http://goo.gl/ZleWCk * -XOverlappingI
Categories: Offsite Discussion

wren gayle romano: On being the "same" or "different": Introduction to Apartness

Planet Haskell - Thu, 08/07/2014 - 3:53am

Meanwhile, back in math land... A couple-few months ago I was doing some work on apartness relations. In particular, I was looking into foundational issues, and into what an apartness-based (rather than equality-based) dependently-typed programming language would look like. Unfortunately, too many folks think "constructive mathematics" only means BHK-style intuitionistic logic— whereas constructive mathematics includes all sorts of other concepts, and they really should be better known!

So I started writing a preamble post, introducing the basic definitions and ideas behind apartnesses, and... well, I kinda got carried away. Instead of a blog post I kinda ended up with a short chapter. And then, well, panic struck. In the interests of Publish Ever, Publish Often, I thought I might as well share it: a brief introduction to apartness relations. As with my blog posts, I'm releasing it under Creative Commons Attribution-NonCommercial-NoDerivs 4.0; so feel free to share it and use it for classes. But, unlike the other columbicubiculomania files, it is not ShareAlike— since I may actually turn it into a published chapter someday. So do respect that. And if you have a book that needs some chapters on apartness relations, get in touch!

The intro goes a little something like this:

We often talk about values being "the same as" or "different from" one another. But how can we formalize these notions? In particular, how should we do so in a constructive setting?

Constructively, we lack a general axiom for double-negation elimination; therefore, every primitive notion gives rise to both strong (strictly positive) and weak (doubly-negated) propositions. Thus, from the denial of (weak) difference we can only conclude weak sameness. Consequently, in the constructive setting it is often desirable to take difference to be a primitive— so that, from the denial of strong difference we can in fact conclude strong sameness.

This ability "un-negate" sameness is the principal reason for taking difference to be one of our primitive notions. While nice in and of itself, it also causes the strong and weak notions of sameness to become logically equivalent (thm 1.4); enabling us to drop the qualifiers when discussing sameness.

But if not being different is enough to be considered the same, then do we still need sameness to be primitive? To simplify our reasoning, we may wish to have sameness be defined as the lack of difference. However, this is not without complications. Sameness has been considered a natural primitive for so long that it has accrued many additional non-propositional properties (e.g., the substitution principle). So, if we eliminate the propositional notion of primitive equality, we will need somewhere else to hang those coats.

The rest of the paper fleshes out these various ideas.

Twitter Facebook Google+ Tumblr WordPress

comments
Categories: Offsite Blogs

wren gayle romano: On being the "same" or "different": Introduction to Apartness

Planet Haskell - Thu, 08/07/2014 - 3:51am

Meanwhile, back in math land... A couple-few months ago I was doing some work on apartness relations. In particular, I was looking into foundational issues, and into what an apartness-based (rather than equality-based) dependently-typed programming language would look like. Unfortunately, too many folks think "constructive mathematics" only means BHK-style intuitionistic logic— whereas constructive mathematics includes all sorts of other concepts, and they really should be better known!

So I started writing a preamble post, introducing the basic definitions and ideas behind apartnesses, and... well, I kinda got carried away. Instead of a blog post I kinda ended up with a short chapter. And then, well, panic struck. In the interests of Publish Ever, Publish Often, I thought I might as well share it: a brief introduction to apartness relations. As with my blog posts, I'm releasing it under Creative Commons Attribution-NonCommercial-NoDerivs 4.0; so feel free to share it and use it for classes. But, unlike the other columbicubiculomania files, it is not ShareAlike— since I may actually turn it into a published chapter someday. So do respect that. And if you have a book that needs some chapters on apartness relations, get in touch!

The intro goes a little something like this:

We often talk about values being "the same as" or "different from" one another. But how can we formalize these notions? In particular, how should we do so in a constructive setting?

Constructively, we lack a general axiom for double-negation elimination; therefore, every primitive notion gives rise to both strong (strictly positive) and weak (doubly-negated) propositions. Thus, from the denial of (weak) difference we can only conclude weak sameness. Consequently, in the constructive setting it is often desirable to take difference to be a primitive— so that, from the denial of strong difference we can in fact conclude strong sameness.

This ability "un-negate" sameness is the principal reason for taking difference to be one of our primitive notions. While nice in and of itself, it also causes the strong and weak notions of sameness to become logically equivalent (thm 1.4); enabling us to drop the qualifiers when discussing sameness.

But if not being different is enough to be considered the same, then do we still need sameness to be primitive? To simplify our reasoning, we may wish to have sameness be defined as the lack of difference. However, this is not without complications. Sameness has been considered a natural primitive for so long that it has accrued many additional non-propositional properties (e.g., the substitution principle). So, if we eliminate the propositional notion of primitive equality, we will need somewhere else to hang those coats.

The rest of the paper fleshes out these various ideas.

Twitter Facebook Google+ Tumblr WordPress

comments
Categories: Offsite Blogs

Haskell uber Alles!

Haskell on Reddit - Thu, 08/07/2014 - 2:48am
Categories: Incoming News