News aggregator

Connection between Monad, Functor and Applicative

Haskell on Reddit - Sat, 07/19/2014 - 7:14am


as far as I understand Monad, Functor and Applicative definitely have something in common. For example, is there any instance of Applicative that isn't basically:

instance Applicative Foo where pure = return (<*>) = ap

Also, is every Monad a Functor and Applicative or are there examples for types that are only one of the three classes?

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

Please Critique my First Project - A Bitcoin Market API Client

Haskell on Reddit - Sat, 07/19/2014 - 1:56am

Hiya, so I've spent the last 2 months or so learning Haskell. I've finished the UPenn course, LYAH and a little bit of RWH.

I wanted to get a project going so I tried making an API client for the CampBX Bitcoin Market[1]. I started out by following along with the FPComplete Mailchimp API Tutorial[2].

I'm asking you beautiful people for any feedback on it so I can be sure that I'm on the right track here, stuff like code style/idioms, project layout, public interface, implementation, docs, ideas for new features, anything you want to tell me, etc.:

Typical usage would be something like this[3]:

main :: IO () main = do cfg <- defaultCampBXConfig _ <- runCampBX cfg $ do totalAskVolume <- calculateAskVolume <$> getDepth liftIO . putStrLn $ "Total Ask Volume: " ++ show totalAskVolume return () calculateAskVolume :: Depth -> BTCAmount calculateAskVolume depthList = sum . map askAmount . asks $ depthList where askAmount (Ask (_, q)) = q

There are still some things I want to work on:

  • Define Asks and Bids[4] using Record Syntax. The JSON[5] for a Bid/Ask comes back as a 2 item Array but the generically derived instance[6] expects an object. I haven't completely wrapped my head around Aeson's Array parsing...
  • Write tests. I'm imagining they would be more "given this JSON, make sure the data structure is created correctly" instead of property-based testing.
  • Use something other than Doubles to represent Amounts + Prices. Is there a standard library for accurate math with decimals(I need up to 8 decimal places)? I suppose I could always just use Integers to represent Satoshis(the smallest subunit of bitcoins).

Also I tried adding "default-extensions: OverloadedStrings" to the .cabal file and removing the pragmas from the source files, but the package wouldn't build :(







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

When did you learn haskell?

Haskell on Reddit - Sat, 07/19/2014 - 12:18am

I have been programming for 4-5 years, and i have been evolving my skills constantly, i have a CompSci degree, but i still feel like i am self-taught.

I have done a wide variety of stuff, but almost always OOP. Now i want to grasp the functional side, i really dont quite get what is all about yet.

I guess my questions are:

1) When did you learn functional programming, and was haskell your first func lang, if not, what was?

2) How has functional programming changed you way of programming?

3) Do you apply functional techiques successfully in non pure functional languages? (Eg. JavaScript)

submitted by gkunno
[link] [19 comments]
Categories: Incoming News

How should I learn Haskell?

Haskell on Reddit - Fri, 07/18/2014 - 11:14pm

I've been studying Python for a while, I finished up Learn Python the Hard Way, and I'm feeling really comfortable in that language. I decided next I'd learn Haskell, because I want to learn a functional language, and I hear it's a great way to get introduced into functional programming. So my question is, where do I go/what do I do to learn Haskell? I generally prefer physical books when I study things, it just works better for me, but if that's not the best way to learn Haskell, let me know!

EDIT: Thanks for your help everyone! Looks like I'll be buying LYAH!

submitted by PM_ME_WHATEVER_IM_BI
[link] [21 comments]
Categories: Incoming News

Avoiding BlockedIndefinitelyOnSTM exceptions

glasgow-user - Fri, 07/18/2014 - 9:13pm
Have you seen ezyang's post here? Lots of hairy details that are probably relevant Brandon
Categories: Offsite Discussion

Edward Kmett on Hask

Haskell on Reddit - Fri, 07/18/2014 - 9:08pm
Categories: Incoming News

Proposal: add 'equating' function to Data.List

libraries list - Fri, 07/18/2014 - 8:26pm
Hi, A common use case for 'on' (from Data.Function) is to use it with 'compare', e.g. 'compare `on` snd'. In fact, this pattern is so common that there's a convenient 'comparing' function which provides a shortcut for this use case such that one can write sortBy (comparing snd) instead of sortBy (compare `on` snd) I think another common use case is to use 'on' together with (==) as in groupBy ((==) `on` snd) In a similiar vein as with 'comparing', I think it would be nice if there was a function which encapsulates this use case, like equating :: Eq b => (a -> b) -> a -> a -> Bool equating = on (==) such that one can write groupBy (equating snd) In fact, groupBy is just one of many *By functions taking an a -> a -> Bool
Categories: Offsite Discussion

Keeping data synched between client/server?

Haskell on Reddit - Fri, 07/18/2014 - 6:08pm

Hey again. So, on my way to learning Haskell I've met another tricky problem. How do you keep data synchronised between client/server? Usually (on C++ etc) the approach would be to manually write socket messages for everything you want to synchronise. Can we do better? I guess some fast diff/patch algorithm for algebraic datatypes would be very handy?

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

Danny Gratzer: A Tutorial on Church Representations

Planet Haskell - Fri, 07/18/2014 - 6:00pm
Posted on July 19, 2014

I’ve written a few times about church representations, but never aimed at someone who’d never heard of what a church representation is. In fact, it doesn’t really seem like too many people have!

In this post I’d like to fix that :)

What is a Church Representation

Simply put, a church representation (CR) is a way of representing a piece of concrete data with a function. The CR can be used through an identical way to the concrete data, but it’s comprised entirely of functions.

They where originally described by Alanzo Church as a way of modeling all data in lambda calculus, where all we have is functions.


The simplest CR I’ve found is that of a tuples.

Let’s first look at our basic tuple API

type Tuple a b = ... mkTuple :: a -> b -> Tuple a b fst :: Tuple a b -> a snd :: Tuple a b -> b

Now this is trivially implemented with (,)

type Tuple a b = (a, b) mkTuple = (,) fst = Prelude.fst snd = Prelude.snd

The church representation preserves the interface, but changes all the underlying implementations.

type Tuple a b = forall c. (a -> b -> c) -> c

There’s our church pair, notice that it’s only comprised of ->. It also makes use of higher rank types. This means that a Tuple a b can be applied to function producing any c and it must return something of that type.

Let’s look at how the rest of our API is implemented

mkTuple a b = \f -> f a b fst tup = tup (\a _ -> a) snd tup = tup (\_ b -> b)

And that’s it!

It’s helpful to step through some reductions here

fst (mkTuple 1 2) fst (\f -> f 1 2) (\f -> f 1 2) (\a _ -> a) (\a _ -> a) 1 2 1

And for snd

snd (mkTuple True False) fst (\f -> f True False) (\f -> f True False) (\_ b -> b) (\_ b -> b) True false False

So we can see that these are clearly morally equivalent. The only real question here is whether, for each CR tuple there exists a normal tuple. This isn’t immediately apparent since the function type for the CR looks a lot more general. In fact, the key to this proof lies in the forall c part, this extra polymorphism let’s us use a powerful technique called “parametricity” to prove that they’re equivalent.

I won’t actually go into such a proof now since it’s not entirely relevant, but it’s worth noting that both (,) and Tuple are completely isomorphic.

To convert between them is pretty straightforward

isoL :: Tuple a b -> (a, b) isoL tup = tup (,) isoR :: (a, b) -> Tuple a b isoR (a, b) = \f -> f a b

Now that we have an idea of how to church representations “work” let’s go through a few more examples to start to see a pattern.


Booleans have the simplest API of all

type Boolean = ... true :: Boolean false :: Boolean test :: Boolean -> a -> a -> a

We can build all other boolean operations on test

a && b = test a b false a || b = test a true b when t e = test t e (return ())

This API is quite simple to implement with Bool,

type Boolean = Bool true = True false = False test b t e = if b then t else e

But how could we represent this with functions? The answer stems from test,

type Boolean = forall a. a -> a -> a

Clever readers will notice this is almost identical to test, a boolean get’s two arguments and returns one or the other.

true = \a _ -> a false = \_ b -> b test b t e = b t e

We can write an isomorphism between Bool and Boolean as well

isoL :: Bool -> Boolean isoL b = if b then true else false isoR :: Boolean -> Bool isoR b = test b True False Lists

Now let’s talk about lists. One of the interesting things is lists are the first recursive data type we’ve dealt with so far.

Defining the API for lists isn’t entirely clear either. We want a small set of functions that can easily cover any conceivable operations for a list.

The simplest way to do this is to realize that we can do exactly 3 things with lists.

  1. Make an empty list
  2. Add a new element to the front of an existing list
  3. Pattern match on them

We can represent this with 3 functions

type List a = ... nil :: List a cons :: a -> List a -> List a match :: List a -> b -> (a -> List a -> b) -> b

If match looks confusing just remember that

f list = match list g h

Is really the same as

f [] = g f (x : xs) = h x xs

In this way match is just the pure functional version of pattern matching. We can actually simplify the API by realizing that rather than this awkward match construct, we can use something cleaner.

foldr forms a much more pleasant API to work with since it’s really the most primitive form of “recursing” on a list.

match :: List a -> (a -> List a -> b) -> b -> b match list f b = fst $ foldr list worker (b, nil) where worker x (b, xs) = (f x xs, cons x xs)

The especially nice thing about foldr is that it doesn’t mention List a in its two “destruction” functions, all the recursion is handled in the implementation.

We can implement CR lists trivially using foldr

type List a = forall b. (a -> b -> b) -> b -> b nil = \ _ nil -> nil cons x xs = \ cons nil -> x `cons` xs cons nil foldr list cons nil = list cons nil

Notice that we handle the recursion in the list type by having a b as an argument? This is similar to how the accumulator to foldr gets the processed tail of the list. This is a common technique for handling recursion in our church representations.

Last but not least, the isomorphism arises from foldr (:) [],

isoL :: List a -> [a] isoL l = l (:) [] isoR :: [a] -> List a isoR l f z = foldr f z l Either

The last case that we’ll look at is Either. Like Pair, Either has 3 different operations.

type Or a b = ... inl :: a -> Or a b inr :: b -> Or a b or :: Or a b -> (a -> c) -> (b -> c) -> c

This is pretty easy to implement with Either

type Or a b = Either a b inl = Left inr = Right or (Left a) f g = f a or (Right b) f g = g b

Once again, the trick to encoding this as a function falls right out of the API. In this case we use the type of or

type Or a b = forall c. (a -> c) -> (b -> c) -> c inl a = \f g -> f a inr b = \f g -> g a or x = x

Last but not least, let’s quickly rattle off our isomorphism.

isoL :: Or a b -> Either a b isoL o = o Left Right isoR o :: Either a b -> Or a b isoR o = or o The Pattern

So now we can talk about the underlying pattern in CRs. First remember that for any type T, we have a list of n distinct constructors T1 T2 T3…Tn. Each of the constructors has a m fields T11, T12, T13…

Now the church representation of such a type T is

forall c. (T11 -> T12 -> T13 -> .. -> c) -> (T21 -> T22 -> T23 -> .. -> c) ... -> (Tn1 -> Tn2 -> Tn3 -> .. -> c) -> c

This pattern doesn’t map quite as nicely to recursive types. Here we have to take the extra step of substituting all occurrences of T for c in our resulting church representation.

This is actually such a pleasant pattern to work with that I’ve written a library for automatically reifying a type between its church representation and concrete form.

Wrap Up

Hopefully you now understand what a church representation is. It’s worth noting that a lot of stuff Haskellers stumble upon daily are really church representations in disguise.

My favorite example is maybe, this function takes a success and failure continuation with a Maybe and produces a value. With a little bit of imagination, one can realize that this is really just a function mapping a Maybe to a church representation!

If you’re thinking that CRs are pretty cool! Now might be a time to take a look at one of my previous posts on deriving them automagically.

<script type="text/javascript"> /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ var disqus_shortname = 'codeco'; // required: replace example with your forum shortname /* * * DON'T EDIT BELOW THIS LINE * * */ (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = '//' + disqus_shortname + ''; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })(); </script> <noscript>Please enable JavaScript to view the comments powered by Disqus.</noscript> comments powered by Disqus
Categories: Offsite Blogs

Functional Programing-Oriented Machine LearningStartup Seeks DevOps Guru

haskell-cafe - Fri, 07/18/2014 - 4:35pm
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Conduit & state

haskell-cafe - Fri, 07/18/2014 - 2:15pm
Hi! I have: runUnixServer (serverSettings socket) $ \appData -> appSource appData $$ handleBS =$ appSink appData I want to store some data in priority queue in Monad.State and be able to access it inside the handleBS (now: handleBS :: ByteString -> ByteString). Can you send me on the right path? Thanx, Pavel. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

What about anonymous/inline types?

Haskell on Reddit - Fri, 07/18/2014 - 1:26pm

It was enlightening the first time one notices any kind of expression can be converted to a single tree of inlined anonymous functions and expressions.

bar a b = a + b foo a b = bar a b + bar a b `foo` can be inlined as not to depend on `bar` foo = λa → λb → ((λc → λd → c + d) a b) + ((λc → λd → c + d) a b)

Might be obvious, but I don't know how to apply the same principle to types.

data Bar a = B a a data Foo = Foo Bar Bar data Foo = forall a. Foo (B a a) (B a a) -- ?? Nonsense submitted by SrPeixinho
[link] [5 comments]
Categories: Incoming News

Ken T Takusagawa: [gggpgqye] Narrow type signatures which can be widened

Planet Haskell - Fri, 07/18/2014 - 10:55am

Create a tool to find type signatures that are less polymorphic than would be inferred by type inference.

This is a solution in search of a problem.

Categories: Offsite Blogs

Unable to build vector on OSX (ghc 7.4, gcc 4.8)

haskell-cafe - Fri, 07/18/2014 - 10:30am
Hi guys, I am currently unable to build vector on OSX: Loading package base ... <command line>: can't load .so/.DLL for: /Applications/ (dlopen(/Applications/, 9): no suitable image found. Did find: /Applications/ mach-o, but wrong filetype) cabal: Error: some packages failed to install: vector- failed during the building phase. The exception was: This has been reported before as some kind of clang issue, but I am using gcc 4.8 (ghc-7.4.2/settings has "gcc-4.8" for "C compiler command"). Any suggestions? Thanks! Edsko _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Mark Jason Dominus: On uninhabited types and inconsistent logics

Planet Haskell - Fri, 07/18/2014 - 10:01am

Earlier this week I gave a talk about the Curry-Howard isomorphism. Talks never go quite the way you expect. The biggest sticking point was my assertion that there is no function with the type a → b. I mentioned this as a throwaway remark on slide 7, assuming that everyone would agree instantly, and then we got totally hung up on it for about twenty minutes.

Part of this was my surprise at discovering that most of the audience (members of the Philly Lambda functional programming group) was not familiar with the Haskell type system. I had assumed that most of the members of a functional programming interest group would be familiar with one of Haskell, ML, or Scala, all of which have the same basic type system. But this was not the case. (Many people are primarily interested in Scheme, for example.)

I think the main problem was that I did not make clear to the audience what Haskell means when it says that a function has type a → b. At the talk, and then later on Reddit people asked

what about a function that takes an integer and returns a string: doesn't it have type a → b?

If you know one of the HM languages, you know that of course it doesn't; it has type Int → String, which is not the same at all. But I wasn't prepared for this confusion and it took me a while to formulate the answer. I think I underestimated the degree to which I have internalized the behavior of Hindley-Milner type systems after twenty years. Next time, I will be better prepared, and will say something like the following:

A function which takes an integer and returns a string does not have the type a → b; it has the type Int → String. You must pass it an integer, and you may only use its return value in a place that makes sense for a string. If f has this type, then 3 + f 4 is a compile-time type error because Haskell knows that f returns a string, and strings do not work with +.

But if f had the type a → b, then 3 + f 4 would be legal, because context requires that f return a number, and the type a → b says that it can return a number, because a number is an instance of the completely general type b. The type a → b, in contrast to Int → String, means that b and a are completely unconstrained.

Say function f had type a → b. Then you would be able to use the expression f x in any context that was expecting any sort of return value; you could write any or all of:

3 + f x head(f x) "foo" ++ f x True && f x

and they would all type check correctly, regardless of the type of x. In the first line, f x would return a number; in the second line f would return a list; in the third line it would return a string, and in the fourth line it would return a boolean. And in each case f could be able to do what was required regardless of the type of x, so without even looking at x. But how could you possibly write such a function f? You can't; it's impossible.

Contrast this with the identity function id, which has type a → a. This says that id always returns a value whose type is the same as that if its argument. So you can write

3 + id x

as long as x has the right type for +, and you can write

head(id x)

as long as x has the right type for head, and so on. But for f to have the type a → b, all those would have to work regardless of the type of the argument to f. And there is no way to write such an f.

Actually I wonder now if part of the problem is that we like to write a → b when what we really mean is the type ∀a.∀b.a → b. Perhaps making the quantifiers explicit would clear things up? I suppose it probably wouldn't have, at least in this case.

The issue is a bit complicated by the fact that the function

loop :: a -> b loop x = loop x

does have the type a → b, and, in a language with exceptions, throw has that type also; or consider Haskell

foo :: a -> b foo x = undefined

Unfortunately, just as I thought I was getting across the explanation of why there can be no function with type a → b, someone brought up exceptions and I had to mutter and look at my shoes. (You can also take the view that these functions have type a → ⊥, but the logical principle ⊥ → b is unexceptionable.)

In fact, experienced practitioners will realize, the instant the type a → b appears, that they have written a function that never returns. Such an example was directly responsible for my own initial interest in functional programming and type systems; I read a 1992 paper (“An anecdote about ML type inference”) by Andrew R. Koenig in which he described writing a merge sort function, whose type was reported (by the SML type inferencer) as [a] -> [b], and the reason was that it had a bug that would cause it to loop forever on any nonempty list. I came back from that conference convinced that I must learn ML, and Higher-Order Perl was a direct (although distant) outcome of that conviction.

Any discussion of the Curry-Howard isomorphism, using Haskell as an example, is somewhat fraught with trouble, because Haskell's type logic is utterly inconsistent. In addition to the examples above, in Haskell one can write

fix :: (a -> a) -> a fix f = let x = fix f in f x

and as a statement of logic, is patently false. This might be an argument in favor of the Total Functional Programming suggested by D.A. Turner and others.

Categories: Offsite Blogs

wren gayle romano: Toward a Projectivistic Theory of Gender, Identity, and Social Categorization

Planet Haskell - Fri, 07/18/2014 - 5:39am

As discussed last time there's a deep-seated problem with performativity as a theory of social categorization. Specifically, it puts the focus on the wrong thing. That our actions are performative in nature gives us important insight into the role agency plays both in forming our own identities and in defending those identities against silencing, marginalization, oppression, and colonialism. But, by centering discussions of identity on our own personal agency we miss out on other important facets of the issue. When we say that someone belongs to a category, we do so because we've decided they belong to the category, or because we think they belong to the category. The statement that they belong to the category is not merely true (or false), we are projecting it to be true (or false). That is, we do not passively observe people's gender, race, class, etc; instead we actively project our own notions of gender, race, class, etc upon them. This projecting of beliefs onto others is called projectivism[1].

Interestingly, by localizing "truth" as the beliefs we hold to be true[2], the projective act is itself performative: by projecting something to be true, one comes to believe that it is true. And yet there is no reason to suppose these beliefs are correct (local truths need not be global truths), nor that they will agree with others' beliefs (local truths need not be true in other locales). Crucially, in the case of categorizing or identifying ourselves, we have access to our own personal thoughts, feelings, memories, subconscious inclinations, etc. Whereas, when others are categorizing us, they do not; they can only observe our bodies, our actions, and the results of our actions. Thus arises the discrepancy in cases like transgenderism. When self-identifying, we may well prize our internal observations over our externally observable state. Nevertheless, others will continue to project their categorizations upon us, regardless of our self-identification.

Not only do people project categories onto others, we do it compulsively. Our persistent and ubiquitous gendering of others is an especially powerful example, but it is in no way unique. Projecting race is another example. And in professional cultures where there are sharply contested borders between "tribes" (e.g., academia and hacker culture), projecting these "tribes" is yet another. This compulsive projectivism —or, more particularly, our unconsciousness of it— is where issues arise.

When we are not typically confronted with evidence that our projections are mistaken, our projectivism becomes almost unconscious. Once there, we fail to notice the fact that we are actively projecting and we come to believe we're passively observing truths about the world. So when our projections turn out to be mistaken, we get a feeling of betrayal, we feel like the person whose identity we were mistaken about was "lying" to us. This subsequent projection that they were "lying" stems from the fact that we mistook our earlier projections for mere observations. Thus, because of an original error on our part, we end up imputing that others are being dishonest or deceptive.

When the identity one desires to be seen as (which may differ from the identity they claim for themselves) is often or easily at odds with the identities projected upon them, they understandably become concerned about trying to avoid these projections of "lying". If one can successfully avoid projections of "lying" they are said to "pass", terminology which turns around and suggests that they were in fact lying the whole time and only managed not to get caught. This terminology is, of course, deeply problematic.

Simply acknowledging compulsive projectivism is not enough. To undo the damage caused by misgendering, racial profiling, stereotyping, and other misprojections, we must lift this knowledge up and remain consciously aware that the beliefs we project onto others are not an observation of their identities. We must denaturalize the projectivist assumption that our beliefs are others' truths, by discontinuing the use words like "passing" which rely on that assumption. And when we feel betrayed we must locate that feeling within ourselves and stop projecting it in bad faith. The performative theory highlights the positive role of agency in our lives, but agency alone is not enough. The projectivistic theory extends this to highlight the negative role of agency when used to deny or overwhelm the agency of others.

[1] I do not mean this terminology to be the same as Hume's notion of projectivism, though of course both terms have the same etymology. Hume's projectivism is popular in the ethics literature, with which I am largely unfamiliar; thus, my use of the term here is not meant to entail whatever baggage it may have accrued in that literature.

[2] While it is not usually presented as such, Austin's original definition of performative speech acts should also only hold up to localized truth. In the classical example "I now pronounce you married", by saying the words one does the deed of pronouncing the couple to be married. However, the pronouncement of marriage does not cause the couple to be married in a universal sense; it only causes them to be married in the current jurisdiction, and a different jurisdiction may or may not recognize that marriage as valid. Because the marriage must be localized, therefore the pronouncement of marriage must be localized: one can't pronounce a couple to be married (everywhere), they can only pronounce them to be married (here, or there, or wherever). Thus, the deed performed by the utterance of the words is a localized deed: the pronouncement of a localized wedding.

Twitter Facebook Google+ Tumblr

Categories: Offsite Blogs

wren gayle romano: I've forgotten how to write

Planet Haskell - Fri, 07/18/2014 - 5:37am

I've forgotten how to write. Somewhere along the way I've forgotten how to say, what I mean. Little sticks and thistles, they burrow under your skin like dry wind and the leaves you brush from your faces. And you find yourself there, looking over, looking out, and turn to tell another how you came to this place, this pretty place, and all you find are tangled weeds and hills and where was the path where you left that friend you thought had come with you

I have half a dozen half written posts, if half written means written and my mind keeps telling me to edit to edit to go over once more, unable to let go, unable to let slip a word lest it falls all out and i somehow say what i somehow mean and someone takes offense. Offence. That word of our times, that police baton with which we beat the helpless, refuse to listen to the stories, those stories once heard we proclaim have "set us free" but we leave the authors beaten, unwilling to look at their lives lest we feel too closely the grip of that truncheon in our fist.

Half a dozen half written posts, weeks of thoughts writ out, on programs and mathematics and words and history. Thoughts I cannot set free. They haunt me, they call me beckoning to spill once again that mental blood to pore and pore over them and wring them dry of every drip of humanity so I can hang out the scraps and let others see how terribly clever i am. I never wanted to be clever, never wanted to be seen like that. I only wanted, once, to be free. From the heartache of a harrowing life, from the illusions and false idols, from my own ignorance. And now these thoughts tie me up in clever little knots, and have me writing bad poetry

Twitter Facebook Google+ Tumblr

Categories: Offsite Blogs

wren gayle romano: A Word on Words

Planet Haskell - Fri, 07/18/2014 - 5:35am

I'd like to take this moment to point out that all forms of binarism are bad. (Including the binarist notion that all things are either "good" or "bad".) I feel like this has to be pointed out because we, every one of us, has a nasty habit: in our overzealousness to tear down one binary, we do so by reinforcing other binaries. So let me say again. All forms of binarism are bad.

It's well-known that I've had a long, fraught history with certain "feminist" communities, due to which I have heretofore disavowed that label. Because of these persistent conflicts, around ten years ago I retreated from feminist circles and communities. However, over the past year I have rejoined a number of feminist circles— or rather, I have joined womanist, black feminist, transfeminist, and queer feminist circles. And thanks to this reinvolvement with feminist activism I have come, once again, to feel a certain attachment to that word: "feminist". The attachment feels strange to me now, having disavowed it for so long in favor of "womanism", "black feminism", "transfeminism", and "queer feminism". But because of this attachment I feel, once more, the need to reclaim feminism away from those "feminist" communities whose philosophy and political methods I continue to disavow.

So, to piss everyone off once more: a manifesto. )

Edit 2014.07.13: Added footnotes [2] and [3].

Twitter Facebook Google+ Tumblr

Categories: Offsite Blogs

wren gayle romano: Performativity is not performance

Planet Haskell - Fri, 07/18/2014 - 5:34am

Although the words have superficially similar pronunciations, performativity and performance are two extremely different notions. In her book Gender Trouble (1990) and its sequel Bodies That Matter (1993), Judith Butler put forth the thesis that gender identity is performative. Over the last decade performance-based theories of gender and identity have become popular, even mainstream, despite a number of deep-seated and readily-apparent flaws. Unfortunately, these latter performance-based theories are often portrayed as successors of Butlerean performativity. They're not.[1]

To understand performativity one should go back to Austin's original definition of performative speech acts. Whenever we speak, we speak for a reason. Austin was interested in explaining these reasons— in particular, explaining the contrast between what we say and why we say it. When we ask "could you pass the salt?" we are not literally interested in whether the addressee is capable of moving the salt shaker, we're making a request. When we ask "how do you do?" or "what's up?" we do not actually want an answer, we are merely greeting someone. It is within this context of discussing the why behind what we say that Austin became interested in performative speech acts: speech acts which through their very utterance do what it is they say, or speech acts which are what it is they mean. When the right person in the right context utters "I now pronounce you married", that vocalization is in fact the pronouncement itself. To state that you pronounce something, is itself to make the proclamation. In just the same way, when under the right circumstances someone says they promise such-and-so, they just did.

There are a number of interesting details about what it means to be a performative speech act. For instance, just uttering the words is not enough: if a random stranger comes up to you and pronounces you married, that does not actually mean you're married. For the performative speech act to have any force it must be uttered in a felicitous context (e.g., the words must be spoken with the proper intent, the pronouncer of marriage must be ordained with the ability to marry people, the partners must be willing, the pairing must be of an appropriate sort according to the bigotry of the times, etc). Another detail is that performative speech acts do more than just enact what they say, they also create something: pronouncing a marriage constructs the marriage itself, declaring war brings the war into existence, giving a promise makes the promise, sentencing someone creates the sentence, etc. Because of details like these, claiming that a particular speech act is performative says a heck of a lot more than just saying the act was performed (i.e., spoken).

On the other hand, a performance is the enactment of a particular variety of artistic expression ranging from theatrical plays, to musical opuses, to religious ceremonies, to performance art, and so on. Whether a particular act is performative is independent of whether it is (a part of) a performance. Many performative speech acts are of a ceremonial nature (e.g., marriages, divorces, christenings, declarations of war, etc) and consequently we like to make a big affair of it. Thus, these particular acts tend to be both: they're performative performances. However, many other performative speech acts are executed with little fanfare: ordering food in a restaurant, apologizing, accepting apologies, resigning from a game, etc. These are all performative acts, and yet there's absolutely no need for any sort of performance behind them. Indeed we often find it humorous, or rude, or severe, when someone chooses to turn these performative acts into performances.

The distinction between performativity and performance is crucial to understanding the thesis Butler put forth. We can expand the idea of performativity to include not just speech acts, but other acts as well. Doing so, Butler's thesis is that one's identity as a particular gender is not something which exists a priori, but rather that it is constructed by the enactment —and especially the continuous ritualistic re-enactment— of performative gender actions. The specific claim being made is that one's gender identity is an artifact whose ontological existence arises from particular deeds, in the exact same way that a marriage is an artifact arising from nuptial ceremony, that a promise is an artifact arising from the swearing of a vow, that a state of war is an artifact arising from the declaration of its existence, and so on. The performative theory of gender is often paraphrased as "gender is something we do"— but this paraphrase is grossly misleading. The paraphrase elides the entire specific content of the thesis! Sure, gender is something we do, but it's something we do in very specific ways and it is in virtue of doing those things in those ways that we come to identify with our gender. That's the thesis.

As discussed before, there are some crucial issues with performativity as a theory of gender. (Though these issues can be corrected by changing the focus without giving up the crucial insight.) But the issue with performativity has nothing whatsoever to do with the fact that performances are artificial, that performances are interruptible, that performances can be altered on whimsy, that performances can be disingenuous, that performances are "only" art, etc. Those latter complaints are why performance-based theories of gender are flat out wrong. And they're evidence of why claiming that performance-based theories were built upon performative theories grossly misconceptualizes performativity.

[1] Don't take my word for it, Butler herself has continually argued that performance-based theories are a gross misinterpretation of her work (Gender Trouble, xxii–xxiv; Bodies That Matter, 125–126; "Gender as Performance: An interview with Judith Butler", 32–39; Judith Butler (by Sara Salih), 62–71).

Twitter Facebook Google+ Tumblr

Categories: Offsite Blogs