Most everyone I talk to about haskell is already a programmer with their own favorite languages. What are some small, interesting/amazing things I can show people on a whiteboard to explain the power of haskell?
I'm looking (vaguely) for examples somewhat like 2.3 and 3.3 from here, or maybe like these examples I found. But, I'm hoping to find examples that can be given more on the fly, and at a somewhat high-language level to "evangelize" with, for lack of a better term.
Ideally the examples would be plain word examples that could be scratched out on a whiteboard impromptu. So for the above I might describe it something along the lines of "you could write out the sheep linage as "sheep, dad, dad's mom" ... etc. But if one of the sheep didn't have a parent, the entire chain would return "nothing". However in haskell you can write out monads to simplify the entire thing down to "grandma = sheep's mom's mom" and it takes care of all the possible lack of parents because of the monad class ... etc."
I realize haskell's true power comes from the paradigm shift you experience when programming, and from other things that are not as easy to explain, especially briefly or high-level, but rather have to be somewhat experienced on your own. That being said, can you guys think of any examples, even so?submitted by thang1thang2
[link] [69 comments]
Decided to play with TChan last night, made a little worker pool + queue example. How would you improve it?
Primary concerns are on practicality, production readiness, etc. without making example too verbose.
Things I already know could be done:
- Use TQueue (more efficient)
- Use TBQueue (bounded and more efficient - back-pressure is difficult to do right)
- Instead of sinking into side effects, send results as Async promises downstream or back to worker supervisor
- Rate limiting (I mean above and beyond limiting worker pool size)
- Dynamic adjustment of worker pool size in response to workload
- Worker status updates, monitoring - I was thinking of maybe checking queue/chan size and submission of "time to complete last task" rolling metrics to get an idea of "how backed up are we?"
- Use Pipes, pipes-concurrency, MVC, Conduit, Iteratees, io-streams, or simple-conduit - using any of these wouldn't change my operational/visibility concerns.
It's fine if you want to elaborate on any of the above, but they don't need mentioned now that I have.
Any ideas? This was inspired by a friend diving into Pipes recently to see if he could be happier with some Haskell code he was using at work. I was partly trying to see if the CSP'ish patterns I'm accustomed to "translate" to Haskell nicely.
I'm quite satisfied so far, but I know it's very naïve still.submitted by Mob_Of_One
[link] [8 comments]
Rust introduced it's package manager Cargo , and has the following feature:If I have three packages: - uno depends on json 1.3.6 - dos depends on json 1.4.12 - tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres.
I don't believe Cabal works like this (encouraging the use of SemVer  to version and aid dependency resolution of packages)
I know the way Cabal works is well-thought out. Would we want to do the same for Cabal, or is it trying to solve a harder problem (and what do we gain)?
(I looked at http://www.haskell.org/cabal/FAQ.html#dependencies-conflict briefly)Platz
[link] [13 comments]
Chapters 4 and 5 capture much of the experience of transitioning and of being trans, respectively. These are the chapters which so many trans memoirs convey in their narration, though often they avoid stating it quite so directly. Both chapters do a good job of conveying the lived experience of trans women, and are well worth reading by cis audiences for that reason.
( Read more... )
Chapter 5 especially was nice to read as it cuts to the core of the fact that there are both conscious and subconscious components to our experiences of (our own) gender. ( Read more... )
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.