News aggregator

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

Clojure's Transducers are Perverse Lenses

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

/u/tel was playing around with a translation of Clojure's transducers to Haskell here. He introduced a type

type Red r a = (r -> a -> r, r)

which reminded me of non-van Laarhoven lenses

type OldLens a b = (a -> b -> a, a -> b)

We can change tel's Red slightly

type Red r a = (r -> a -> r, () -> r)

From this point of view, Red is a perverse form of lens, because the "getter" always returns the same value, which is the value a normal lens would extract a value from! I think the modified "van Laarhoven form" of Red reads

type PerverseLens r a = forall f. Functor f => (() -> f a) -> a -> f r

but I'm not sure. I suspect that you'll be able to use normal function composition with this encoding somehow, and it will compose "backwards" like lenses do. After about 15 minutes, I haven't gotten anywhere, but I'm a Haskell noob, so I'm curious if someone more experienced can make this work.

/u/tel also defined reducer transformers

type RT r a b = PerverseLens r a -> PerverseLens r b

From the "perverse lens" point of view, I believe an RT would be equivalent to

(. perverseGetter)

where a PerverseGetter is PerverseLens specialized to Const, in the same way Getter is Lens specialized to Const.

I'm not sure how helpful or useful any of this is, but it is interesting.

EDIT: Perhaps

type Red r a = (r -> a -> r, (forall x. x -> r)) type PerverseLens r a = forall f. Functor f => (forall x. x -> f a) -> a -> f r

would be better types for perverse lenses?

submitted by kidnapster
[link] [23 comments]
Categories: Incoming News

I Did A Haskell: fizzbuzz

Haskell on Reddit - Wed, 08/06/2014 - 9:07pm
fizzbuzz :: [Integer] -> [String] fizzbuzz [] = [] fizzbuzz xs = [ let fz = if mod x 3 == 0 then "fizz" else [] in let bz = if mod x 5 == 0 then "buzz" else [] in let fzbz = fz ++ bz in if null fzbz then show x else fzbz | x <- xs ]

I started the Learn You A Haskell tutorial, and as soon as I hit the boomBangs example I was like "ooh! ooh!" and had to do fizzbuzz. I have no idea if this is anywhere close to idiomatic (or whether there's any benefit to declaring the null case explicitly, here). First working version had fz and bz as functions in a where clause because I couldn't figure out how to inline them, which amuses me in retrospect because, ha ha, in lines -- anyway, I suspect that my original version is more proper, but dammit, I'm proud of myself. :D

Okay, done gushing at the internet for now, but this here thing is neat.

submitted by tejon
[link] [26 comments]
Categories: Incoming News

Oliver Charles: Working with postgresql-simple with generics-sop

Planet Haskell - Wed, 08/06/2014 - 6:00pm

The least interesting part of my job as a programmer is the act of pressing keys on a keyboard, and thus I actively seek ways to reduce typing. As programmers, we aim for reuse in a our programs - abstracting commonality into reusable functions such that our programs get more concise. Functional programmers are aware of the benefits of higher-order functions as one form of generic programming, but another powerful technique is that of data type generic programming.

This variant of generic programming allows one to build programs that work over arbitrary data types, providing they have some sort of known “shape”. We describe the shape of data types by representing them via a code - often we can describe a data type as a sum of products. By sum, we are talking about the choice of a constructor in a data type (such as choosing between Left and Right to construct Either values), and by product we mean the individual fields in a constructor (such as the individual fields in a record).

Last month, Edsko and Löh announced a new library for generic programming: generics-sop. I’ve been playing with this library in the last couple of days, and I absolutely love the approach. In today’s short post, I want to demonstrate how easy it is to use this library. I don’t plan to go into a lot of detail, but I encourage interested readers to check out the associated paper - True Sums of Products - a paper with a lovely balance of theory and a plethora of examples.

postgresql-simple

When working with postgresql-simple, one often defines records and corresponding FromRow and ToRow instances. Let’s assume we’re modelling a library. No library is complete without books, so we might begin with a record such as:

data Book = Book { bookTitle :: Text , bookAuthor :: Text , bookISBN :: ISBN , bookPublishYear :: Int }

In order to store and retrieve these in our database, we need to write the following instances:

instance FromRow Book where toRow = Book <$> field <*> field <*> field <*> field instance ToRow Book where toRow Book{..} = [ toField bookTitle , toField bookAuthor , toField bookISBN , toField bookPublishYear ]

As you can see - that’s a lot of boilerplate. In fact, it’s nearly twice as much code as the data type itself! The definitions of these instances are trivial, so it’s frustrating that I have to manually type the implementation bodies by hand. It’s here that we turn to generics-sop.

First, we’re going to need a bit of boiler-plate in order to manipulate Books generically:

data Book = ... deriving (GHC.Generics.Generic) instance Generics.SOP.Generic Book

We derive generic representations of our Book using GHC.Generics, and in turn use this generic representation to derive the Generics.SOP.Generic instance. With this out of the way, we’re ready to work with Books in a generic manner.

generics-sop

The generics-sop library works by manipulating heterogeneous lists of data. If we look at our Book data type, we can see that the following two are morally describing the same data:

book = Book "Conceptual Mathematics" "Lawvere, Schanuel" "978-0-521-71916-2" 2009 book = [ "Conceptual Mathematics", "Lawvere, Schanuel", "978-0-521-71916-2", 2009 ]

Of course, we can’t actually write such a thing in Haskell - lists are required to have all their elements of the same type. However, using modern GHC extensions, we can get very close to modelling this:

data HList :: [*] -> * where Nil :: HList '[] (:*) :: x -> HList xs -> HList (x ': xs) book :: HList '[Text, Text, ISBN, Int] book = "Conceptual Mathematics" :* "Lawvere, Schanuel" :* "978-0-521-71916-2" :* 2009 :* Nil

Once we begin working in this domain, a lot of the techniques we’re already familiar with continue fairly naturally. We can map over these lists, exploit their applicative functor-like structure, fold them, and so on.

generics-sop continues in the trend, using kind polymorphism and a few other techniques to maximise generality. We can see what exactly is going on with generics-sop if we ask GHCI for the :kind! of Book’s generic Code:

> :kind! Code Book Code Book = SOP I '[ '[ Text, Text, ISBN, Int ] ]

The list of fields is contained within another list of all possible constructors - as Book only has one constructor, thus there is only one element in the outer list.

FromRow, Generically

How does this help us solve the problem of our FromRow and ToRow instances? First, let’s think about what’s happening when we write instances of FromRow. Our Book data type has four fields, so we need to use field four times. field has side effects in the RowParser functor, so we sequence all of these calls using applicative syntax, finally applying the results to the Book constructor.

Now that we’ve broken the problem down, we’ll start by solving our first problem - calling field the correct number of times. Calling field means we need to have an instance of FromField for each field in a constructor, so to enforce this, we can use All to require all fields have an instance of a type class. We also use a little trick with Proxy to specify which type class we need to use. We combine all of this with hcpure, which is a variant of pure that can be used to build a product:

fields :: (All FromField xs, SingI xs) => NP RowParser xs fields = hcpure fromField field where fromField = Proxy :: Proxy FromField

So far, we’ve built a product of field calls, which you can think of as being a list of RowParsers - something akin to [RowParser ..]. However, we need a single row parser returning multiple values, which is more like RowParser [..]. In the Prelude we have a function to sequence a list of monadic actions:

sequence :: Monad m => [m a] -> m [a]

There is an equivalent in generics-sop for working with heterogeneous lists - hsequence. Thus if we hsequence our fields, we build a single RowParser that returns a product of values:

fields :: (All FromField xs, SingI xs) => RowParser (NP I xs) fields = hsequence (hcpure fromField field) where fromField = Proxy :: Proxy FromField

(I is the “do nothing” identity functor).

Remarkably, these few lines of code are enough to construct data types. All we need to do is embed this product in a constructor of a sum, and then switch from the generic representation to a concrete data type. We’ll restrict ourselves to data types that have only one constructor, and this constraint is mentioned in the type below (Code a ~ '[ xs ] forces a to have only one constructor):

gfrowRow :: (All FromField xs, Code a ~ '[xs], SingI xs, Generic a) => RowParser a gfrowRow = to . SOP . Z <$> hsequence (hcpure fromField field) where fromField = Proxy :: Proxy FromField

That’s all there is to it! No type class instances, no skipping over meta-data - we just build a list of field calls, sequence them, and turn the result into our data type.

ToRow, Generically

It’s not hard to apply the same ideas for ToRow. Recall the definition of ToRow:

class ToRow a where toRow :: a -> [Action]

toRow takes a value of type a and turns it into a list of actions. Usually, we have one action for each field - we just call toField on each field in the record.

To work with data generically, we first need move from the original data type to its generic representation, which we can do with from and a little bit of pattern matching:

gtoRow :: (Generic a, Code a ~ '[xs]) => a -> [Action] gtoRow a = case from a of SOP (Z xs) -> _

Here we pattern match into the fields of the first constructor of the data type. xs is now a product of all fields, and we can begin turning into Actions. The most natural way to do this is simply to map toField over each field, collecting the resulting Actions into a list. That is, we’d like to do:

map toField xs

That’s not quite possible in generics-sop, but we can get very close. Using hcliftA, we can lift a method of a type class over a heterogeneous list:

gtoRow :: (Generic a, Code a ~ '[xs], All ToField xs, SingI xs) => a -> [Action] gtoRow a = case from a of SOP (Z xs) -> _ (hcliftA toFieldP (K . toField . unI) xs) where toFieldP = Proxy :: Proxy ToField

We unwrap from the identity functor I, call toField on the value, and then pack this back up using the constant functor K. The details here are a little subtle, but essentially this moves us from a heterogeneous list to a homogeneous list, where each element of the list is an Action. Now that we have a homogeneous list, we can switch back to a more basic representation by collapsing the structure with hcollapse:

gtoRow :: (Generic a, Code a ~ '[xs], All ToField xs, SingI xs) => a -> [Action] gtoRow a = case from a of SOP (Z xs) -> hcollapse (hcliftA toFieldP (K . toField . unI) xs) where toFieldP = Proxy :: Proxy ToField

Admittedly this definition is a little more complicated than one might hope, but it’s still extremely concise and declarative - there’s only a little bit of noise added. However, again we should note there was no need to write type class instances, perform explicit recursion or deal with meta-data - generics-sop stayed out of way and gave us just what we needed.

Conclusion

Now that we have gfromRow and gtoRow it’s easy to extend our application. Perhaps we now want to extend our database with Author objects. We’re now free to do so, with minimal boiler plate:

data Book = Book { bookId :: Int , bookTitle :: Text , bookAuthorId :: Int , bookISBN :: ISBN , bookPublishYear :: Int } deriving (GHC.Generics.Generic) instance Generic.SOP.Generic Book instance FromRow Book where fromRow = gfromRow instance ToRow Book where toRow = gtoRow data Author = Author { authorId :: Int , authorName :: Text , authorCountry :: Country } deriving (GHC.Generics.Generic) instance Generic.SOP.Generic Author instance FromRow Author where fromRow = gfromRow instance ToRow Author where toRow = gtoRow

generics-sop is a powerful library for dealing with data generically. By using heterogeneous lists, the techniques we’ve learnt at the value level naturally extend and we can begin to think of working with generic data in a declarative manner. For me, this appeal to familiar techniques makes it easy to dive straight in to writing generic functions - I’ve already spent time learning to think in maps and folds, it’s nice to see the ideas transfer to yet another problem domain.

generics-sop goes a lot further than we’ve seen in this post. For more real-world examples, see the links at the top of the generics-sop Hackage page.

Categories: Offsite Blogs

cabal repl failing silently on missing exposed-modules

glasgow-user - Wed, 08/06/2014 - 3:18pm
Hi, I have just spent some time trying to figure out why all of a sudden "cabal repl" silently exits without an error message. What helped was to take a project that could launch the repl and compare the cabal files to my new project. It turns out the exposed-modules entry was missing. I was wondering whether this behaviour was intentional, as I don't recollect this happening before, but I don't have older systems to test this on. The reason I wanted to run a repl without editing exposed modules was to test some dependencies I pulled in to the sandbox with cabal install. The package in question didn't have any code of its own yet. In this case I would just expect ghci to load with the Prelude. Thanks!
Categories: Offsite Discussion

How would you make a falling sand game in Haskell?

Haskell on Reddit - Wed, 08/06/2014 - 2:51pm

Background: a falling sand game is this. Basically, various types of particles have very naive physics.

So basically, the usual/imperative approach would be to have a list of particles and update them one at a time. For speed, there would be a 2d-array to quickly look up if there is a particle at a position.

It seems like there should be a more idiomatic approach in Haskell. I've thought about it, but even something as simple as abstracting the looping construct seems tricky.

submitted by tailcalled
[link] [26 comments]
Categories: Incoming News

PureScript By Example

Haskell on Reddit - Wed, 08/06/2014 - 11:06am
Categories: Incoming News

wren gayle romano: Imagine that this is not an academic debate

Planet Haskell - Wed, 08/06/2014 - 9:56am

A followup to my previous [reddit version]:

The examples are of limited utility. The problem is not a few bad apples or a few bad words; were that the case it would be easier to address. The problem is a subtle one: it's in the tone and tenor of conversation, it's in the things not talked about, in the implicitization of assumptions, and in a decentering of the sorts of communities of engagement that Haskell was founded on.

Back in 2003 and 2005, communities like Haskell Cafe were communities of praxis. That is, we gathered because we do Haskell, and our gathering was a way to meet others who do Haskell. Our discussions were centered on this praxis and on how we could improve our own doing of Haskell. Naturally, as a place of learning it was also a place of teaching— but teaching was never the goal, teaching was a necessary means to the end of improving our own understandings of being lazy with class. The assumptions implicit in the community at the time were that Haskell was a path to explore, and an obscure one at that. It is not The Way™ by any stretch of the imagination. And being a small community it was easy to know every person in it, to converse as you would with a friend not as you would online.

Over time the tone and nature of the Cafe changed considerably. It's hard to explain the shift without overly praising the way things were before or overly condemning the shift. Whereas the Cafe used to be a place for people to encounter one another on their solitary journeys, in time it became less of a resting stop (or dare I say: cafe) and more of a meeting hall. No longer a place to meet those who do Haskell, but rather a place for a certain communal doing of Haskell. I single the Cafe out only because I have the longest history with that community, but the same overall shift has occurred everywhere I've seen. Whereas previously it was a community of praxis, now it is more a community of educationalism. In the public spaces there is more teaching of Haskell than doing of it. There's nothing wrong with teaching, but when teaching becomes the thing-being-done rather than a means to an end, it twists the message. It's no longer people asking for help and receiving personal guidance, it's offering up half-baked monad tutorials to the faceless masses. And from tutorialization it's a very short path to proselytizing and evangelizing. And this weaponization of knowledge always serves to marginalize and exclude very specific voices from the community.

One class of voices being excluded is women. To see an example of this, consider the response to Doaitse Swierstra's comment at the 2012 Haskell Symposium. Stop thinking about the comment. The comment is not the point. The point is, once the problematic nature of the comment was raised, how did the community respond? If you want a specific example, this is it. The example is not in what Swierstra said, the example is in how the Haskell community responded to being called out. If you don't recall how this went down, here's the reddit version; though it's worth pointing out that there were many other conversations outside of reddit. A very small number of people acquitted themselves well. A handful of people knew how to speak the party line but flubbed it by mansplaining, engaging in flamewars, or allowing the conversation to be derailed. And a great many people were showing their asses all over the place. Now I want you to go through and read every single comment there, including the ones below threshold. I want you to read those comments and imagine that this is not an academic debate. Imagine that this is your life. Imagine that you are the unnamed party under discussion. That your feelings are the ones everyone thinks they know so much about. That you personally are the one each commenter is accusing of overreacting. Imagine that you are a woman, that you are walking down the street in the middle of the night in an unfamiliar town after a long day of talks. It was raining earlier so the streets are wet. You're probably wearing flats, but your feet still hurt. You're tired. Perhaps you had a drink over dinner with other conference-goers, or perhaps not. Reading each comment, before going on to the next one, stop and ask yourself: would you feel safe if this commenter decided to follow you home on that darkened street? Do you feel like this person can comprehend that you are a human being on that wet street? Do you trust this person's intentions in being around you late at night? And ask yourself, when some other commenter on that thread follows you home at night and rapes you in the hotel, do you feel safe going to the author of this comment to tell them what happened? Because none of this is academic. As a woman you go to conferences and this is how you are treated. And the metric of whether you can be around someone is not whether they seem interesting or smart or anything else, the metric is: do you feel safe? If you can understand anything about what this is like, then reading that thread will make you extremely uncomfortable. The problem is not that some person makes a comment. The problem is that masculinized communities are not safe for women. The problem is that certain modes of interaction are actively hostile to certain participants. The problem is finding yourself in an uncomfortable situation and knowing that noone has your back. Knowing that anyone who agrees with you will remain silent because they do not think you are worth the time and energy to bother supporting. Because that's what silence says. Silence says you are not worth it. Silence says you are not one of us. Silence says I do not think you are entirely human. And for all the upvotes and all the conversation my previous comment has sparked on twitter, irc, and elsewhere, I sure don't hear anyone here speaking up to say they got my back.

This is not a problem about women in Haskell. Women are just the go-to example, the example cis het middle-class educated able white men are used to engaging. Countless voices are excluded by the current atmosphere in Haskell communities. I know they are excluded because I personally watched them walk out the door after incidents like the one above, and I've been watching them leave for a decade. I'm in various communities for queer programmers, and many of the folks there use Haskell but none of them will come within ten feet of "official" Haskell communities. That aversion is even stronger in the transgender/genderqueer community. I personally know at least a dozen trans Haskellers, but I'm the only one who participates in the "official" Haskell community. Last fall I got hatemail from Haskellers for bringing up the violence against trans women of color on my blog, since that blog is syndicated to Planet Haskell. Again, when I brought this up, people would express their dismay in private conversations, but noone would say a damn thing in public nor even acknowledge that I had spoken. Ours has never been a great community for people of color, and when I talk to POC about Haskell I do not even consider directing them to the "official" channels. When Ken Shan gave the program chair report at the Haskell symposium last year, there was a similarly unwholesome response as with Swierstra's comment the year before. A number of people have shared their experiences in response to Ken's call, but overwhelmingly people feel like their stories of being marginalized and excluded "don't count" or "aren't enough to mention". Stop. Think about that. A lot of people are coming forward to talk about how they've been made to feel uncomfortable, and while telling those stories they feel the need to qualify. While actively explaining their own experiences of racism, sexism, heterosexism, cissexism, ablism, sanism, etc, they feel the simultaneous need to point out that these experiences are not out of the ordinary. Experiencing bigotry is so within the ordinary that people feel like they're being a bother to even mention it. This is what I'm talking about. This is what I mean when I say that there is a growing miasma in our community. This is how racism and sexism and ablism work. It's not smacking someone on the ass or using the N-word. It's a pervasive and insidious tone in the conversation, a thousand and one not-so-subtle clues about who gets to be included and who doesn't. And yes the sexual assaults and slurs and all that factor in, but that's the marzipan on top of the cake. The cake is made out of assuming someone who dresses "like a rapper" can't be a hacker. The cake is made out of assuming that "mother" and "professional" are exclusive categories. The cake is made out of well-actuallys and feigned surprise. And it works this way because this is how it avoids being called into question. So when you ask for specific examples you're missing the point. I can give examples, but doing so only contributes to the errant belief that bigotry happens in moments. Bigotry is not a moment. Bigotry is a sustained state of being that permeates one's actions and how one forms and engages with community. So knowing about that hatemail, or knowing about when I had to call someone out for sharing titty pictures on Haskell Cafe, or knowing about the formation of #nothaskell, or knowing about how tepid the response to Tim's article or Ken's report were, knowing about none of these specifics helps to engage with the actual problem.

Twitter Facebook Google+ Tumblr WordPress

comments
Categories: Offsite Blogs

How do you apply your knowledge of Haskell to popular OO languages?

Haskell on Reddit - Wed, 08/06/2014 - 7:54am

I'm just curious; I assume most of us don't have day jobs/typically work directly in Haskell. How much of your Haskell knowledge transfers effectively to your work, particularly if you're using a popular Object-Oriented language like Ruby or Java?

In my case, I've recognized major abstractions when using Javascript (the engine of one of my main projects at work is essentially a bunch of cokleisli composition), but JS has first-class functions which make this kind of thing easy(isn) to work recognize and work with.

What kind of things have you learned in Haskell that help you out with working in other (large) systems written heavily in non-functional languages?

submitted by 5outh
[link] [47 comments]
Categories: Incoming News