I'm finally getting around to reading Julia Serano's Whipping Girl (2007), and I thought I'd make a few comments as I go along.
The first couple chapters are, by and large, an introduction to the terminology standard in gender studies and transgender circles. For those already familiar, it's light reading; though there are a few important notes of positioning. The first, and one I agree with wholeheartedly, is explicitly stating that "sex" is a socially constructed concept— exactly as "gender" is. ( Read more... )
The second positioning Serano makes is one I take issue with. Serano names herself a feminist and considers her work in exposing and discussing trans issues to be part of the feminist enterprise. ( Read more... )
The most interesting point so far is her distinguishing between anti-female ideologies and anti-feminine ideologies. The distinction between femaleness and femininity should make sense to anyone. Serano goes a bit further in trying to systematically distinguish them and to identify when particular acts serve to subjugate women vs subjugating femmes. Feminism, for example, is very pro-female and has successfully built a world where it is natural to say "men and women are equal"; however, it has done so largely at the cost of sacrificing femininity— a woman can do anything a man can do, just so long as she's not too girly about it. I very much hope Serano delves into this topic more.
Today’s 1HaskellADay problem was an interesting NP-hard problem ... until I reread the problem statement carefully, then it became trivial. ‘Consecutive’ is the keyword here that unlocked the puzzle for me, eventually.
The heart of the algorithm here is simple enough. It says, in words, ‘are these next n numbers in the list the sum specified?’ If they are, return them as a solution, if they are greater, return nothing, if they are less than the sum, keep trying.
Those are the words, here is the implementation:
inquiry :: Int -> Int -> DList Int -> [Int] -> [Int]inquiry _ _ _  = inquiry goal sub accum (next : rest) = let tote = sub + next naccum = accum << next in case (compare tote goal) of LT -> inquiry goal tote naccum rest EQ -> dlToList naccum GT -> 
Simple enough, and I use a difference list as an accumulator, just because that’s how I roll (and the fact, too, that difference lists append an element in constant time is sweet!)
So, now all we need to do is move an index over the list to test each possible scenario.
Enter the (Comonad) Dragon
Of course, iterating over a list, keeping the context of the list itself active can be done functionally in many ways, but what suggested itself to me right away was the Comonad.
The Comonad of the list is the list itself and all of its tails, and this is exactly the paradigm we need to solve this problem simply, so, writing matchingSub became simply a comonadic extension:
matchingSub’ :: Int -> [Int] -> [[Int]]matchingSub’ goal domain = domain =>> inquiry goal 0 emptyDL
Now, this doesn’t quite give the requested solution sets for the given examples, as it returns the empty list as ‘no solution,’ not ‘nothing at all’ as requested, but filtering out the empty list is easy enough: we just need a predicate to test if the list is not empty and then return only the lists of answers:
isCons :: [a] -> BoolisCons  = FalseisCons _ = True
matchingSub :: Int -> [Int] -> [[Int]]matchingSub goal = filter isCons . matchingSub’ goal
And there we have it!
I like comonads. They’re sweet!
Okay, prove it, buster!
(Who is this 'buster'-person, by the way, and why is he always having to prove things?)
All the above code is in Haskell programming, but it is also mutually-translatable to and from Idris. Nearly the same syntax (intentionally so), and nearly the same semantics (Idris's eager evalution looks and tastes very much like Haskell's normal order evaluation).
In Haskell, we'd hand-verify the above with the provided samples and we're done. We'd run it through quickcheck to be done-done.
In Idris, we can prove that what we specified is actually (heh: 'actually') correct in its implementation.
So, let's prove it.
prvSample : (expected : List (List Int)) -> (actual : List (List Int)) -> (so (expected == actual)) -> ()prvSample expected actual pred = ()
Using the 'so' assertion, we're (almost) done.
Let's run our sample-set through our prover, such that it is:
sample1 : ()sample1 = (prvSample [[1..4]] (matchingSub 10 [1..5])) oh
sample2 : ()sample2 = (prvSample [[1,1], [1,1]] (matchingSub 2 $ replicate 3 1)) oh
sample3 : ()sample3 = (prvSample [[1,1], [1,1]] (take 2 $ matchingSub 2 $ repeat 1)) oh
Code compiles? Yes? We're done: we've delivered functionality as specified.
Currently, the instructions for using Stackage say that one should modify the remote-repo in ~/.cabal/config, e.g., from the latest Stackage build for GHC 7.6, 2014-06-21.
However, in order to have ~/.cabal/config in the first place, one must first run cabal update which works with Hackage by default.
So, the question is: how to do the initial cabal update to use Stackage right away in the case when ~/.cabal/config and ~/.cabal/ghc folders do not exist yet? I could not find any parameters for cabal nor cabal update.
The second question is: isn't there any negative impact of running cabal update from Hackage first and then switching the remote-repo to Stackage?
The third question is: how to use Stackage within cabal sandboxes?
Is it possible to somehow have Stackage as primary and Hackage as secondary remote-repo so that packages missing from Stackage are automatically looked up on Hackage?
[link] [13 comments]
The Implicit Calculus: A New Foundation for Generic ProgrammingBruno C. D. S. Oliveira, Tom Schrijvers, Wontae Choi, Wonchan Lee, Kwangkeun Yi, Philip Wadler. Draft paper, 2014.
Generic programming (GP) is an increasingly important trend in programming languages. Well-known GP mechanisms, such as type classes and the C++0x concepts proposal, usually combine two features: 1) a special type of interfaces; and 2) implicit instantiation of implementations of those interfaces.
Scala implicits are a GP language mechanism, inspired by type classes, that break with the tradition of coupling implicit instantiation with a special type of interface. Instead, implicits provide only implicit instantiation, which is generalized to work for any types. Scala implicits turn out to be quite powerful and useful to address many limitations that show up in other GP mechanisms.
This paper synthesizes the key ideas of implicits formally in a minimal and general core calculus called the implicit calculus (\lambda_?), and it shows how to build source languages supporting implicit instantiation on top of it. A novelty of the calculus is its support for partial resolution and higher-order rules (a feature that has been proposed before, but was never formalized or implemented). Ultimately, the implicit calculus provides a formal model of implicits, which can be used by language designers to study and inform implementations of similar mechanisms in their own languages.
Share and enjoy!
The School of Computer Science at the University of Nottingham in the UK is seeking to appoint a new Assistant Professor: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI181514
Applications in the area of the Functional Programming (FP) lab would be most welcome. The FP lab is keen to receive applications from candidates with an excellent publication record, experience in combining theory with practice, and the ability to secure external funding to support their research. Further information about the FP lab is available from: http://fp.cs.nott.ac.uk
The deadline for applications is Friday 22nd August 2014. The advert mentions computer vision, but the position is open to applicants from any area of Computer Science.
Graham Huttonsubmitted by grahamhutton
[link] [3 comments]