winterkoninkje: shadowcrane (clean) (Default)
2016-04-27 06:03 pm

Hacking projects over the next few months

Life’s been really hectic lately, but I’ve been getting (slowly) back into working on my Haskell packages. In particular, since the switch from darcs to github I’ve started getting more comments and feature requests, which is nice. Over the next half-year or so, here’s what I’ll be up to in my free time between work on the dissertation and work on Hakaru:

containers — I’ve been appointed one of the new co-maintainers of our favorite venerable library. I prolly won’t be doing any major work until autumn (as mentioned when I was appointed), but I’ve had a number of conversations with David Feuer about where to take things in terms of cleaning up some old maintenance cruft.

bytestring-trie — A few years back I started reimplementing my tries to use Bagwell’s Array Mapped Tries in lieu of Okasaki’s Big-Endian Patricia Tries, but then got stalled because life. I’ve started up on it again, and it’s just about ready to be released after a few more tweaks. Also, now that I’m working on it again I can finally clear out the backlog of API requests (sorry folks!).

exact-combinatorics — A user recently pointed me towards a new fast implementation of factorial making waves lately. It’s not clear just yet whether it’ll be faster than the current implementation, but should be easy enough to get going and run some benchmarks.

unification-fd — This one isn’t hacking so much as dissemination. I have a backlog of queries about why things are the way they are, which I need to address; and I’ve been meaning to continue the tutorial about how to use this library for your unification needs.

logfloat — We’ve been using this a lot in Hakaru, and there are a few performance tweaks I think I can add. The main optimization area is trying to minimize the conditionals for detecting edge cases. The biggest issue has just been coming up with some decent benchmarks. The problem, of course, is that most programs making use of logfloats do a lot of other work too so it can be tricky to detect the actual effect of changes. I think this is something Hakaru can help a lot with since it makes it easy to construct all sorts of new models.

winterkoninkje: shadowcrane (clean) (Default)
2016-04-24 07:08 pm

Quantifiers in type theory

All this stuff is "well known", but I want to put it out there for folks who may not have encountered it, or not encountered it all together in one picture.

The Damas–Hindley–Milner type system (i.e., the type system that Algorithm W is inferring types for) is propositional logic extended with rank-1 second-order universal quantifiers. It is interesting because it is so particularly stable with respect to inference, decidability, etc. That is, we can come up with many other algorithms besides Algorithm W and they enjoy nice properties like the fact that adding type signatures won't cause inference to fail. (It's worth noting, that Algorithm W is DEXPTIME-complete; so while in practice it's often linear time, for pathological inputs it can take exponentially long. However, if we put a constant bound on the depth of nested let-bindings, then the upper bound becomes polynomial.)

The extension of DHM with rank-1 second-order existential quantifiers is strictly more powerful. It is interesting because it allows unrestricted use of both of the quantifiers in prenex position; thus, it is the limit/top of the alternating quantifier hierarchy (à la the arithmetical hierarchy) that starts with DHM. Surely there are other interesting properties here, but this system is understudied relative to the ones above and below. Edit: Although GHC gets by with encoding existentials away, it's worth noting that MLF allows existentials where the unpacking is implicit rather than requiring an "unseal" or case eliminator (Leijen 2006); and also that UHC does in fact offer first-class existentials (Dijkstra 2005).

The extension with rank-2 second-order universals (i.e., where the universal quantifier can appear to the left of one function arrow) is strictly more powerful still. Here we can encode rank-1 existentials, but my point in this whole post is to point out that rank-1 existentials themselves are strictly weaker than the rank-2 universals it takes to encode them! Also, one little-known fact: this type system is interesting because it is the last one in this progression where type inference is decidable. The decidability of rank-2 universal quantification is part of the reason why GHC distinguishes between -XRank2Types vs -XRankNTypes. Alas, although inference is decidable —and thus of mathematical interest— it is not decidable in the same robust way that DHM is. That is, if we care about human factors like good error messages or not breaking when the user adds type signatures, then we don't get those properties here. Still, the fact that this system is at the cusp of decidable inference is important to know. Edit: Also of interest, this system has the same typeable terms as simply-typed λ-calculus with rank-2 intersection types, and the type inference problem here is fundamentally DEXPTIME-complete (Jim 1995).

Things keep alternating back and forth between existentials and universals of each rank; so far as I'm aware, none of these systems are of any particular interest until we hit the limit: rank-ω (aka: rank-N) second-order quantification. This type system is often called "System F", but that's a misnomer. It is important to differentiate between the syntactic system (i.e., actual System F) we're inferring types for, vs the type system (aka: propositional logic with second-order quantifiers) in which the inferred types live. That is, we can perfectly well have a syntactic system which doesn't have explicit type abstractions/applications but for which we still ascribe rank-ω types. It so happens that the type inference problem is undecidable for that syntactic system, but it was already undecidable way back at rank-3 so the undecidability isn't particularly novel.

winterkoninkje: shadowcrane (clean) (Default)
2016-04-08 03:49 am
Entry tags:

The problem with ableism is where to begin

I’ve been trying to write a post. Been trying to write a hundred posts, but it’s all a tangle, whenever I try pulling one of the threads the whole ball knots up. Don’t know where to begin, because where can you start when the disease began before you entered the world, because what can you say when you’ve spent so long convincing yourself you have nothing to say? That tangle of where to start, seems like it’s the sort of thing that only ever goes away after you’ve already been talking. I never knew where to start with my psychic pain, back when I joined Bodies Under Siege, I only learned the words for everything I felt after talking so long with other survivors. But back then I had the luxury of anonymity. Had the freedom to explore the boundaries of myself in that anonymized community without worry for repercussions.

Having spent so long convincing myself I’ve nothing to say, it’s like I can’t speak my current mind without first unleashing that backlogged torrent. But I think, really, it’s all ableism. It’s this,… this,… we spend so much time denying the voices of the disabled, I feel like I’m not allowed to speak, feel like before I can claim that mantle I must first earn my street cred. Like, before I can write my post on living with chronic pain, first I must quantify for you what that pain is like lest you don’t believe I have it. Like, before I can write my post on invisibility, I can’t tell you how I’ve been trained to invisibilize myself without also first convincing you there’s something to be hidden beneath that cloak. Like, before I can write my post on internalized ableism, I have to have already told you my whole story —a story over a third of a century in the making, but also a story tangled up in so many other things that aren’t disability but which intersect with my disability. But I can’t tell you that story, not the way I see it, without telling it through the lens of the ableism of which I wished to speak.

But all this inability to speak before having spoken, I know it’s just ableism. Know it’s a tool of the able-bodied system, a tool they beat into us when we’re young, to make sure those who don’t fit the mould stay silent. It’s why I don’t comment or complain about a daily level of pain that’s high enough that OTC painkillers no longer help. It’s why when I do bring up out of the ordinary pain, I’m never believed; doctors are all, “it can’t be that bad if you’re only just mentioning it. Try some advil.” Just exactly like the police to a survivor of rape, “it can’t be all that bad if you’re only just mentioning it. Try not wearing slutty clothes.” And it’s not even the pain that worries me. It’s the feeling of inadequacy. Ableism is the belief that everyone already meets some standard specification of ability and productivity, that anyone who doesn’t measure up is just lazy, is cheating the system, isn’t shouldering their allocated duties, is a burden on the good responsible people, that those who truly “through no fault of their own” can’t reach those specifications are so rare that if you were one you’d already know and you’d never question so why don’t you just suck it up already. It’s the Protestant work ethic that says no matter how hard you work it’s never good enough. It’s why we feel like frauds, why we work so hard it breaks us, for fear of falling behind, for fear of losing everything because of a bad day. It’s that other impostor syndrome, the one that no matter how bad things get you can’t ever shake the worry that it’s all “in your head”, that you’re “making it up for sympathy”, that “it’s really not that bad”.

And all of this is why I can’t even begin to speak. For my experiences of ableism are all filtered through being a survivor of rape, being a survivor of a conservative Christian childhood, being a survivor of psychological torture and gaslighting, being a woman, being queer, and I can’t but draw the obvious and necessary parallels, but those parallels only elucidate if you too have survived these things.

winterkoninkje: shadowcrane (clean) (Default)
2016-04-07 02:54 am

Dissertating, ahoy!

Usually whenever we think about gradschool we think about the switch from "doing classwork, quals, etc" to "dissertating" is a single-step process, which we call "becoming a PhD candidate" (as opposed to being a PhD student). In practice there are over half a dozen steps. Filing the paperwork declaring your completion of classwork, quals, etc is just the first few. (Okay, easy enough) Then there's the prospectus, for the graduate school. (The what for the who now?) Then the forming of your research committee. (Right, okay) Then the proposal. (Wait, how is this different from the other thing?) Then the proposal defense. (Um, okay, but not every department requires this?) Plus a few other steps I'm surely forgetting.

As of yesterday, I am officially finally totally completely absolutely done with all the paperwork, and can finally get back to actually working on the thesis itself!

winterkoninkje: shadowcrane (clean) (Default)
2016-04-03 11:12 pm
Entry tags:

Monthly Update

A lot’s been happening this last month. I’ve started at least half a dozen posts, but can’t seem to find the time/energy to finish any of them. Whence the radio silence. So, in lieu of interesting content, an update on life:

At the end of February I solved the hard problem in my thesis!! I’ve been banging my head against that problem for well over a year. So how’d it happen? I had a meeting with one of my advisors to talk about coalgebras for a different project entirely, and something in there got me thinking. (ProTip: always think more about coalgebras.) That weekend I decided to take a whack at the problem again and managed to get everything to work out. Ultimately the solution involves a novel extension to the standard approach for proving strong normalization via logical predicates. On March 4th I gave an impromptu talk at the local PL seminar about the technique. And was planning on spending the next week and a half cranking out an ICFP submission detailing the technique (since it’s of interest outside my thesis), but then...

I’ve mentioned before about how my mother’s been dying. Near the end of February she went to the hospital again; since which my dad gave me and my siblings daily updates on what’s happening. Then on the 6th my dad called and said I needed to come out. So me and L booked a last-minute trip out there for a couple days. It was... stressful, to put it mildly. But I got to catch up with two of my nieces, so that part was cool. On the 30th it was official. The funeral is in the next couple days.

A week after getting back from the last-minute trip to Maryland, me and L went on our anniversary holiday. Last year we rented a cabin in the woods, and it was pretty awesome being woken up by cows and going for hikes. So we decided to do it again this year, though this time we went to Brown county here in Indiana (last year it was in Ohio). OMG this state is misogynistic, homophobic, and transphobic! I mean, I’ve known this; but Bloomington is a lot better about hiding it than the rest of the state. Plus, there wasn’t really anywhere good for hiking. The cabin itself was pretty nice, but the rest: ugh. We ended up deciding to head home a day early; just couldn’t deal with how awful the people there were. At least we got to bond over how terrible it all was ;)

And then going on a week ago, my kidneys decided it’s time to murder me again. I’ve gone to the ER three times already for kidney stones, so I’m pretty clear on what the symptoms are. Figured this time I’d try to see a doctor first, to get some pain meds before I need to be hospitalized again. To which I got to revisit that fabulous experience where doctors refuse to acknowledge my pain let alone do anything about it. Gotta love it when you’re nauseous, experiencing visual artifacts/hallucinations, completely out of it, and barely able to carry on a conversation but the doctors have already decided before even seeing you that they’re not going to prescribe anything. I never actually get sick from my pain-nausea, no matter how bad it is; I only get sick from the anti-nausea meds they sneak in with major painkillers. But I wish I could/did get sick, dirty up her office a bit: historically that’s been the only thing to make drs take me seriously.

winterkoninkje: shadowcrane (clean) (Default)
2016-02-22 02:16 am
Entry tags:

The last couple weeks

At the beginning of the year I decided to try writing more regularly. For a while things went as planned, but the last few weeks have been sparse. Been dealing with some stuff, and since announcing I’ve accepted the job at Google —or actually, since announcing I was on the job market last fall— I’ve been reluctant to talk about my crazy. I feel hypocritical about it. I know I shouldn’t; most folks don’t talk. But of course, that’s why I feel like a hypocrite. I go on about being open and trying to normalize mental illness, but then when it really matters I go and hide in the closet like everyone else afraid for their jobs. Plus, part of me is all I don’t want to be just another whiny brat on the internet. I know this comes from internalized saneism and puritanical stoicism and all the other repressive shit that makes me want to speak out in the first place, but still, the knowing doesn’t help so much as I’d like for deconstructing that internalized selfhate.

Aside from the internal turmoil, things’ve been going well. (Which, again, makes me feel like shit: for bitching when “I have it good”.) Me and L have been getting shit done in prep for moving out to Mountain View or wherever thereabouts. Been making progress on getting my dissertation rolling again. And finally completed my old task on Hakaru, so now I can move on to new / more interesting stuff with the overall project. Our anniversary is coming up, and we’ve planned our trip. We got our taxes done last weekend and’ll be getting a sizeable return, which’ll help for covering all the incidentals with moving. (Google does cover moving expenses, but those’re payed out on the first paycheck which will, of course, come after we’ve moved.) I went and saw an OT last week re getting splints; got some plastic ones to try out for a bit to be sure they help / are what I want: they do, and are. The followup appointment is scheduled this week for taking measurements to get them ordered, will post pics once they arrive :)

Talking with my therapist last time he asked an interesting question, asked about my experiences of “loss”. At first I didn’t have much to say, couldn’t really think of any. But the more I thought the more came out. I’d never really reflected on loss before. When something pervades so much of your life, you stop noticing it after a while; what use is reflecting on a word that describes the ubiquitous? But I’ve had a lot of it lately, stupid little things mostly (there I go minimizing again) but stupid little things that’ve stirred up bigger beasts from the past. I could say more, but what would it help? I've already talked a bit about my drawing (and my mother, and mortality). Suppose I could spend the next couple posts fleshing out other bits, giving them more time than I really feel up to today. We'll see.

winterkoninkje: shadowcrane (clean) (Default)
2016-02-03 01:21 am

It's official, I'm off to Google

It's official, I'm heading to Google at the end of July to work with Mark Larson on the Chrome OS security team (of all things!). Seems an unlikely match, but Mark was pretty keen on my background (including the gender stuff!) and wasn't put off by my fusion of linguistics, type-theory, constructive logic/maths, et al. I guess the security team is more concerned with semantic models and constructive correctness than the other teams I talked with. Makes sense, I suppose, but it's sad that these are still thought of as "security" concerns rather than "everything in programming" concerns.

I'm totally looking forward to it, but I am still thinking of it as a bit of an experiment. I'm an academic at heart, so I could see myself heading back to academia in a few years. (Wanting to be a professor is, afterall, what motivated me to start gradschool in the first place.) Then again, I've never really thought of industry as being interested in the sorts of theory I work on. In any case, I'll still be around at the various conferences I've been frequenting; I won't just disappear into industry.

I know a bunch of y'all are in the bay area. I'd love to hear any pointers you have on apartment hunting or on what neighborhoods (nearish Mt View) are nice— i.e., places an artistic disabled radical queer woman might like. Feel free to comment below or get in touch by email, twitter, etc.

winterkoninkje: shadowcrane (clean) (Default)
2016-01-28 10:07 pm
Entry tags:

Accidentiality, non-locality, and reconciliation

One of the things that intrigues me most about the rise of the internet is the ways in which it fundamentally alters social structures. Virtual and physical reality afford different forms of interaction, differences people are only beginning to acknowledge. These affordances don't make one aspect of reality "better" than the other, just different. That difference is unavoidable, but my real interest lies in the ways these aspects of reality co-define one another. Events like GamerGate expose how violence can fulminate in virtual spaces until it spills over into physical spaces. But I believe that an understanding of how virtuality and physicality reinforce each other can also be used to construct a safer and more just world.

Over the past week I had a number of conversations with folks about these differences between physicality and virtuality. On tuesday I talked with Rob for a few hours about how economies of information and economies of material are incommensurable (tangled up with a discussion of the systems- and game-theoretic roots of why capitalism is fundamentally flawed)— an interesting topic, but one for another post. But I also talked with S, and later briefly with Lindsey, about an anthropological concern I've been meaning to write about for some while.

There is an unavoidably accidental nature to physical reality. Physicality has an immediacy that cannot be ignored, and the inability to freely reroute through other pathways means we are constantly bumping into one another. Asking a stranger for directions or if this seat is taken; overhearing conversations on the bus; running into that little-known would-be-friend on the street; and yes also the ill-met accidents. In contrast, virtuality is —for now— inescapably intentional. You can't just stumble upon new friendships, but must go looking for them. You can't foster relationships through the familiarity of a quiet presence, but must speak out to maintain them.

To reiterate, neither intentionality nor accidentiality is inherently superior— especially for those of us on the margins. Most of my relationships have started out accidentally. To pick a few: I met K when I happened to audit a class she was in, and she recognized me from the comic store she works at; I met S when she caught me checking her out in a busy hallway; I met L when her boyfriend at the time was ignoring her at a mutual friend's birthday party. None of these interactions are the sort that avail themselves online. We may recognize handles seen elsewhere, but that seldom leads to a "where do I know you from? let's have dinner" moment. While we can flirt online, it's much harder to feel out the other party for whether they're receptive. And we cannot readily see those sitting silent in dejected corners. But despite whatever accidental beginnings, my deepest relationships have always been grown online. Relationships are always forged in a shared vulnerability, but the experiences of us on the margins are often too vulnerable to speak aloud. Exposing the details of a life of violence and minoritization requires the emotional safety of intentional spaces. The abilities to edit, to wait, to breathe, to digest, to scroll through history; for those of us who have never had safety in the physical world, these abilities provide a structure that permits us to to be vulnerable without risking our health.

But while intentionality can be used to construct spaces in which to open ourselves, it also constructs spaces which trap us into ourselves. To find safety in online spaces it is necessary to be able to block out those who would cause us harm; but the intentionality of this blocking out makes it easy to block out too much, and so to lock us into our ways of being. A key example here is the possibility for reconciliation. In any relationship there is always the threat of breakage. When a relationship breaks we block the other out, but in physical spaces these blocks seldom last forever. At first we may avoid places the other frequents, but in time this fades from memory. When living in physical proximity there is always the possibility for an accidental encounter, and in that accident the possibility for reconciliation. Walking down the street we can bump into ex-friends and ex-lovers, and depending on the circumstances of the break, these bumps can provide a means for renewal— to wit: a chance for growth and change. However, in virtual spaces we have no mechanism for such accidents. Once we block or mute others, there is never an incentive to revisit these choices. Ironically, the less we recall the slight —and so the greater the chance for reconciliation—, the less likely we are to revisit the choice, since doing so requires an explicit intention to reconnect, and that intention risks renewing the rupture since it's explicitness calls to mind the reason for the separation.

I think the possibility of reconciliation is necessary for healthy communities. (E.g., the inability to reconcile is, imo, part of why politics in the US have grown ever more polarized.) But it is unclear how to develop a virtual society which affords reconciliation. Simply having blocks expire in some timely fashion is unacceptable; most blocks stem not from broken relationships, but rather from the need to defend oneself from violence. The locality of physical space provides a strong defense against certain forms of violence: you can (at least in principle) move away from bigots and abusers. Whereas the non-locality of virtual space precludes this defense: there is no "elsewhere" to go. Of course, this non-locality is also one of the greatest strengths of virtual spaces, as it enables marginalized peoples to connect over long physical distances.

I don't yet have a conclusion. It's just something I've been thinking about off and on for a few years. And was reminded since bumping into an ex-friend; though, alas, we didn't get the chance to try and reconnect.

winterkoninkje: shadowcrane (clean) (Default)
2016-01-27 12:07 am

Finding hope

Many of us with disabilities have more than one. This multiplicity is invisiblized by the abled community. When our lives are already assumed to be defined by disability, admitting multiplicity risks the hazard of letting the complexities of disabled lives enter one's mind. But even among the disabled, there's a tendency to focus on the one or two things which most obviously impact our lives. This is a coping mechanism. To cope with lacking spoons, we are always prioritizing our energies, and there is never enough to solve all the things. But also, ableism being what it is, we must be careful never to "complain too much" lest we loose whatever ears we've gained; so we consign our suffering to silence, that we might grasp at crumbs of compassion for hope that when things worsen there may still be someone who'll listen.

I have my "one or two things": depression and cPTSD. And I've mentioned my migraines on occasion, though they're seldom of bloggable interest. But there's one I've never talked about, one I've still not come to terms with myself. That's the thing about chronic pain. Noone ever teaches us about all the things that shouldn't hurt, about all the pains most people don't have. And consequently we come to normalize them, to unsee the ways they make us choose —in small ways at first— to restrict our lives. Last week I met a fabulous girl and we got to talking about disability. And with one sentence she cut through me like a thunderbolt, cut through a silence I hadn't even realized I'd been spinning for years. Her words, so simple:

I have a connective tissue disease

I've suspected it for a couple decades, known it for nearly a decade, but it's never been something I've been allowed to talk about. When a teen complains about joint pain, it is dismissed as an insignificance. When a twentysomething does, everyone older jests and jeers; "just wait till you're my age," they say. Sit down. Shut up. Respect your elders. If you're resilient enough to keep at it, to endure the shame and go to a doctor... well, doctors have ways of silencing things they can't cure. When I first saw a doctor for my knees, he acted like it was nothing, like I was a stupid kid bitching about nothing— despite saying, with surprise in his voice, how my x-rays looked like someone 15–20 years older. When I pressed, when I refused to be cowed, he told me there was nothing modern science could do: I could use a splint, but that'd weaken the muscles and exacerbate the problem; I could try working out to strengthen the muscles —at least, for as long as I could stand the pain— but that'd only slow the inevitable by a couple years at best; it wasn't bad enough for surgery, besides that'd just cause even more damage. "You're young," he said in flat monotone, like words rehearsed without meaning. Like pointing out something broken or left behind, when you really don't care if they hear you. Your coffee. Your wallet. Your tail light. You're young.

The thing about genetic issues is that they pervade everything. It's never a singular problem, it's a cascade of them, a death by ten-thousand papercuts. In my childhood, my mother always had issues with her knees. It was almost a joke how often she went in for surgeries on them; the kind of joke people only mumble and noone laughs at but they tell it anyways because they don't know what else to do. During my early college years, her shoulders started going out. A few years back my sister died spontaneously, and within a few months a cousin joined her. Aortic ruptures. In the last year or so, my mother had an aortic dissection. She survived, but more from luck than anything. I happened to be in Maryland when she was in the hospital, and I visited. She'd also been having catastrophic spinal problems. My parents didn't even bother mentioning it until she went in for the first surgery. It didn't go well. Three followup surgeries later and who knows if any of it did any good. Sitting next to her as she lay in that bed, her hands all locked up in pain, held in mine, I could barely look on her. Because I know I'll live to be crippled and die twisted in pain. She's had enough in-patient PT to be released, and is back home now on out-patient PT. Noone talks about it. But at least noone jokes anymore.

I can't say if it was her heart or her back that somehow managed to convince some doctor to take a closer look. He'd thought she had Marfan syndrome and ordered a genetic screening. Tests came back negative. Followups found it's actually Loeys-Dietz, something that wasn't even discovered until ten years ago, and the docs only knew of it because she'd been admitted to the hospital where they discovered it. There's no point in testing the dead, but there's little doubt about what did my sister and cousin in. I've been checked for aortic problems, and show no symptoms as yet. I'll have to get checked again every couple years.

(One of the funniest things about transitioning is how it's been the healthiest decision I've ever made. If I'd've known all the minor health issues it'd cure, I would've fought harder to do it when I was 18. Among the things it helped was my back. While uncommon, HRT can cause corrections in one's hips and lower ribs. Thanks to the changes in my hips and my center of gravity, I no longer have chronic back pain. Growing up I could never attain correct posture: it caused pain and felt unnatural; whereas now it comes freely and without thinking.)

But the litany of little pains isn't what hurts the most. I used to draw. It used to be my life. The fire in my heart, as maths is the breath in my chest. I'd do it when I wasn't thinking. I'd do it to focus my thinking. I'd come home and spend hours at it. I'd ignore eating to finish a piece. I won awards. I thought I'd make a vocation of it. By halfway through undergrad I could barely finish a small sketch in the margins of my notes. Many of my friends are artists (e.g.), and while I love their work, a hateful demon grows in me every time I see their successes or hear them praised. These days I can barely hold a pencil. My script an ever more illegible shorthand as I try to eke out a few more pages before I resign to sitting behind a computer. (The most creative parts of doing math, for me, needs being written. It is only once I have the sketch of a thing can I put it to pixels.) Just bringing up my art, acknowledging it as something lost rather than as something I lost time for, crushes me.

That girl, that blessed fabulous girl. A few days after we'd met I asked her about her ring, a beautiful curious thing, like two rings locked together at an angle. Turns out it's a surgical splint for preventing hyperextension. She told me where to get one, and on the bus yesterday I decided to check out their website. Reading through the descriptions of the rings they offer —I don't even... How do you name that emotion when a pain you've had so long you've forgotten it exists is suddenly eased, that lift, that release, that letting go. Like when you find someone who shares your very same marginalization, that feeling where you can just talk, can let words free without censor knowing they have already been understood before they are spoken. That sudden finding oneself not alone. That slow creeping into existence of a future worth looking toward. I had to turn off my browser. Can't be crying on busses. Can't be weak in public.

winterkoninkje: shadowcrane (clean) (Default)
2016-01-17 01:22 pm

A week of "P"s

The next week+ I'll be in St. Petersburg Florida for PEPM, PADL, POPL, PPS, and PPAML PI (also CPP and OBT). Would've mentioned it sooner, but it's a bit of a last minute thing. I love reconnecting with old friends and meeting new folks, so feel free to come say hi. If you want to meet up for dinner or such, leave a comment with when/where to find you, or just look for the tall gal with the blue streak in her hair.

winterkoninkje: shadowcrane (clean) (Default)
2016-01-08 07:23 pm

Recommitting to blogging in the new year

It's a new year, and the new semester starts next week. To be honest, the last semester ended on a down note: the week of Thanksgiving, depression hit again. It'd been about five years since the last major episode, so better than usual if by just a bit. The last week or so thing's've started looking up again, but who knows how long that'll last or how long till it really clears up.

A bunch of friends, fellow academics with mental illness, have given newyears posts on how they're dealing with their MI; posts I've found somehow more uplifting than I would've expected. And so, thus inspired, I'm hoping to return to blogging regularly. The plan is to post regularly on tuesdays and (prolly irregularly) thursdays. (Edit 2016.01.13) Let's make that regularly on thursdays and irregularly on tuesdays.

So, with that said, I'll see y'all again on tuesday.

winterkoninkje: shadowcrane (clean) (Default)
2015-10-30 01:13 am

Limitations of strongly-typed ABTs

Last time I talked a bit about ABTs; in particular, I introduced the notion of strongly-typed ABTs (or "GABTs" if you prefer) and showed how we can extend the basic idea of ABTs to guarantee well-typedness in addition to well-aritiedness. However, I also made a note that ensuring this sort of well-typedness runs counter to what Neel and other CMUers often do. One of my colleagues here at IU noticed the reason, so I thought I'd write a bit more about it.

The issue at stake here is how general we can make our ABT library, to minimize the amount of boilerplate needed whenever inventing a new language. By encoding object-language type systems into the kinding of the ABT, we restrict the the possible object languages we can use the ABT implementation for (namely those object languages with type systems that can be embedded into whatever kinding the ABT has). To put a finer point on it, using the kinds presented in the previous post you cannot have binders in your type system. (Edit 2016.02.29: actually the details are more complicated.) This means no System F, and no dependent types. This is unfortunate as the whole point of ABTs is to capture binding structure once and for all!

However, I'd like to reiterate that, for our purposes in Hakaru this limitation is no restriction. Hakaru is simply-typed, so there are no type-level binders in sight. Moreover, we do a lot of program transformations in Hakaru. By using GABTs we can have GHC verify that our program transformations will never produce Hakaru code which is ill-typed, and that our program transformations will always produce Hakaru code of an appropriate type (e.g., the same type as the input term, for things like partial evaluation; but we have a number of type-changing transformations too). Thus, even though our GABT library could not be reused for implementing languages with type-level binders, it still provides a substantial benefit for those languages without type-level binders.

Although our GABTs cannot handle type-level binders, that does not mean we're restricted to only working with simply typed languages. For example, intersection types are not usually thought of as "simple types"; but they do not require binders and so they're fine. More generally, Larry Moss is engaged in a research project where he asks, "given infinite time, how far could Aristotle have gotten in logic?" By which he means, given the Aristotelian restriction to syllogistic logics (i.e., ones without the quantifiers introduced by Frege), what are the limits in what we can cover? It turns out that we can cover quite a lot. Some syllogistic logics go beyond the power of the "Peano–Frege" boundary: they can handle comparing cardinality of sets! A good pictorial summary of this line of research is on slide 2 of this talk; and a bit more about the complexity results is given in this talk (the requisite picture is on slide 39).


Edit 2016.02.29: In actuality, there's nothing inherent in type theory that prohibits having type-level binders for our object language; it's a limitation in GHC. In particular, GHC doesn't allow lifting GADTs into data kinds. If we could lift GADTs, then we could simply use ABTs to define the syntax of object-language type expressions, and lift those to serve as the type indices for using ABTs to define the syntax of object-language term expressions. This stratified approach is sufficient to handle System F and any other non-dependent quantifiers. To go further and handle dependent quantifiers as well, we'd also need to be able to define the object-language's terms and types in a mutually inductive way.

winterkoninkje: shadowcrane (clean) (Default)
2015-10-02 04:53 pm
Entry tags:

Groggy Linguistics

I'm sick. I shouldn't be online. But just wanted to prattle on about a thing that'd take too long on twitter. A day or two ago I came across a linguist being cited somewhere in some article about celebrity couple name blends. In it they noted how certain syllables like "klol" and "prar" are forbidden in English. They phrased the restriction as forbidding CRVR (where C means a consonant, R means a liquid/sonorant —I forget how they phrased it—, and V a vowel).

There's something of merit going on here, but the specifics are far more complicated. Note that "slur" is perfectly acceptable. So, well maybe it's just that the C has to be a plosive. But then, "blur" is perfectly fine too. So, well maybe it's something special about how "-ur" forms a stand-alone rhotic vowel. But then "trill" and "drill" are just fine. So, well maybe...

winterkoninkje: shadowcrane (clean) (Default)
2015-09-20 08:01 pm

Abstract Binding Trees in Hakaru

Edit 2015.10.29: Be sure to also read the followup post on the benefits and limitations of this approach compared to the usual untyped ABTs.

Earlier this year Neel Krishnaswami talked about abstract binding trees (ABTs) [part 1] [part 2]. IMO, the best way to think about ABTs is as a generalization of abstract syntax trees (ASTs), though this is not a perspective sanctioned by the CMUers I’ve talked to. CMUers oppose this way of phrasing things, in part, because the ABT libraries they’re familiar with make crucial use of the design pattern of two-level types; but I think the essential insights of ABTs and two-level types are quite different, and we ought to keep the benefits of these two techniques distinct.

Over the past year I’ve been working on the inferential language1 Hakaru, and in the new version of the compiler we’re using ABTs for our syntax trees. However, contrary to Neel’s stance against using strongly-typed internal representations for syntax, we extend the ABT approach to make use of GADTs to guarantee local well-typedness— since this in turn can be used to guarantee that program transformations are also well-typed. (If you don’t want those guarantees, then take a look at Jon Sterling’s abt library on Hackage2.) In this post I’m going to present a simplified version of our architecture, and then talk about some of the extra stuff bringing it closer to our production architecture.

First things first

Since we want everything to be well-typed, we first must introduce some universe, U, of all the types in our language. (In Haskell we can implement such a universe by using the -XDataKinds extension, so I’ll equivocate between calling U a “universe” vs a “kind”.) For the rest of this post it doesn’t actually matter what lives in that universe3, just so long as things match up when they need to. Since the choice of universe is irrelevant, we could abstract over U by turning on the -XPolyKinds extension; but I avoid doing so below, just to help keep things more concrete.

Implementing ASTs

The simplest way of thinking about well-typed ASTs is that they capture the set of terms generated by a (typed) signature; that is, the fixed point of some Σ [U] U . Unpacking the type for Σ, we have that every syntactic constructor sΣ is associated with some arity (the length of the list), each argument to s has some type in U (the elements of the list), and applying s to the right number of ASTs of the right types will generate a new AST with some type in U (the second argument to Σ).

To implement this fixed point we define an AST type which is parameterized by its signature. To ensure well-aritiedness (and well-typedness) of our ASTs with respect to that signature, we’ll need to introduce a helper type SArgs4. And to ensure that we obtain the least fixed-point of the signature, we’ll make everything strict.

infix  4 :$
infixr 5 :*

data SArgs  (U  )  [U]   where
    End   SArgs ast []

    (:*)  !(ast u)
          !(SArgs ast us)
          SArgs ast (u : us)

data AST  ([U]  U  )  U   where
    (:$)  !(σ us u)
          !(SArgs (AST σ) us)
          AST σ u

Implementing ABTs

The problem with ASTs is that they have no notion of variables, and thus have no notion of variable binding. Naively we could implement binders like lambda-abstraction by having something like λ Σ [u, v] (u :→ v) but then we’d need to do a post-hoc check to ensure that the first argument to λ is in fact a variable. To build that check into the datatype itself we’d have to move λ into the definition of AST (since the first argument is of type Variable u rather than AST Σ u). If lambda-abstraction were the only binder we had, that might not be so bad; but any real-world language has a plethora of binders, and this approach doesn’t scale.

The essential idea behind ABTs is to abstract over the notion of binding itself. Given a single uniform definition of what it means to be a binding form, we don’t have to worry about adding a bunch of ad-hoc constructors to our AST datatype. Moreover, we can then provide single uniform definitions for things which mess with variables and are homomorphic over the signature. Things like capture-avoiding substitution and providing a HOAS API for our first-order representation.

The crucial step is to adjust our notion of what a signature contains. The basic signatures used above only contained applicative forms; i.e., things we can apply to locally-closed terms; i.e., what are called “functors” in the logic programming community. For ABTs we’ll want to allow our signatures to include any generalized quantifier. That is, our signatures will now be of type Σ [[U] × U] U . Previously, the arguments were indexed by U; now, they’re indexed by [U] × U. The length of the list gives the number of variables being bound, the types in the list give the types of those variables, and the second component of the pair gives the type of the whole locally-open expression.

To implement this we need to extend our syntax tree to include variable bindings and variable uses:

data SArgs  ([U]  U  )  [[U] × U]   where
    End   SArgs abt []

    (:*)  !(abt vs u)
          !(SArgs abt vus)
          SArgs abt ((vs,u) : vus)

data ABT  ([[U] × U]  U  )  [U]  U   where
    (:$)  !(σ vus u)
          !(SArgs (ABT σ) vus)
          ABT σ [] u

    Var   !(Variable v)
          ABT σ [] v

    Bind  !(Variable v)
          !(ABT σ vs u)
          ABT σ (v : vs) u

Time for an example of how this all fits together. To add lambda-abstraction to our language we’d have λ Σ [([u],v)] (u :→ v): that is, the λ constructor takes a single argument which is a locally-open term, binding a single variable of type u, and whose body has type v. So given some x Variable u and e ABT Σ [] v we’d have the AST (λ :$ Bind x e :* End) ABT Σ [] (u :→ v).

“Local” vs “global” well-typedness

With the ABT definition above, every term of type ABT Σ vs u must be locally well-typed according to the signature Σ. I keep saying “locally” well-typed because we only actually keep track of local binding information. This is an intentional design decision. But only tracking local well-typedness does have some downsides.

So what are the downsides? Where could things go wrong? Given a locally-closed term (i.e., either Var x or f :$ e) any free variables that occur inside will not have their U-types tracked by Haskell’s type system. This introduces some room for the compiler writer to break the connection between the types of a variable’s binder and its use. That is, under the hood, every variable is represented by some unique identifier like an integer or a string. Integers and strings aren’t U-indexed Haskell types, thus it’s possible to construct a Variable u and a Variable v with the same unique identifier, even though u and v differ. We could then Bind the Variable u but Var the Variable v. In order to ensure global well-typedness we need to ensure this can’t happen.

One way is to keep track of global binding information, as we do in the paper presentation of languages. Unfortunately, to do this we’d need to teach Haskell’s typechecker about the structural rules of our language. Without a type-level implementation of sets/maps which respects all the axioms that sets/maps should, we’d be forced to do things like traverse our ASTs and rebuild them identically, but at different type indices. This is simply too hairy to stomach. Implementing the axioms ourselves is doubly so.

Or we could fake it, using unsafeCoerce to avoid the extraneous traversals or the complicated pattern matching on axioms. But doing this we’d erase all guarantees that adding global binding information has to offer.

A third approach, and the one we take in Hakaru, is compartmentalize the places where variables can be constructed. The variable generation code must be part of our trusted code base, but unlike the unsafeCoerce approach we can keep all the TCB code together in one spot rather than spread out across the whole compiler.

Stratifying our data types

The above definition of ABTs is a simplified version of what we actually use in Hakaru. For example, Hakaru has user-defined algebraic data types, so we also need case analysis on those data types. Alas, generic case analysis is not a generalized quantifier, thus we cannot implement it with (:$). We could consider just adding case analysis to the ABT definition, but then we’d start running into extensibility issues again. Instead, we can break the ABT type apart into two types: one for capturing variable uses and bindings, and the other for whatever syntax we can come up with. Thus,

data Syntax  ([[U] × U]  U  )  ([U]  U  )  U   where
    (:$)  !(σ vus u)
          !(SArgs abt vus)
          Syntax σ abt u

data ABT  ([U]  U  )  [U]  U   where
    Syn   !(Syntax σ (ABT σ) u)
          ABT σ [] u

    Var   !(Variable v)
          ABT σ [] v

    Bind  !(Variable v)
          !(ABT σ vs u)
          ABT σ (v : vs) u

Of course, since we’re going to be extending Syntax with all our language-specific details, there’s not a whole lot of benefit to parameterizing over σ. Thus, we can simplify the types considerably by just picking some concrete Σ to plug in for σ.

By breaking Syntax apart from ABT we can now extend our notion of syntax without worrying about the details of variable binding (which can be defined once and for all on ABT). But we could still run into extensibility issues. In particular, often we want to separate the fixed-point portion of recursive types from their generating functor so that we can do things like add annotations at every node in the recursive data type. A prime example of such annotations is keeping track of free variables, as in Neel’s original post. To allow this form of extensibility we need to break up the ABT type into two parts: the recursion, and the Syn/Var/Bind view of the ABT.

data ABT  ([U]  U  )  [U]  U   where
    Unview  !(View σ (ABT σ) vs u)  ABT σ vs u

view  ABT σ vs u  View σ (ABT σ) vs u
view (Unview e) = e

data View  ([U]  U  )  [U]  U   where
    Syn   !(Syntax σ abt u)
          View σ abt [] u

    Var   !(Variable v)
          View σ abt [] v

    Bind  !(Variable v)
          !(View σ abt vs u)
          View σ abt (v : vs) u

Now, to allow arbitrary annotations we’ll replace the data type ABT with an equivalent type class. Each instance of the ABT class defines some sort of annotations, and we can use the view and unview methods to move between the instance and the concrete View type.

There’s one last form of extensibility we may want to add. Using fixed point combinators gives us a way of describing complete trees. A different way of introducing recursion is with free monads. The free-monad combinator is just like the fixed-point combinator, except that we have an additional type parameter for metavariables and we have a data constructor for using those metavariables instead of requiring the recursion to ground out with a complete syntax tree. The reasons why this might be nice to do are beyond the scope of this post, but the point is we might want to do that so we need to split the ABT class into two parts: one for the recursion itself, and another for the annotations.

In the end, we have a four-level type: the Syntax, the View, the annotations, and the recursion.


[1] In the accepted/current parlance, Hakaru is a “probabilistic programming language”; but I and a number of other folks working on such languages have become disaffected with that term of late, since it’s not entirely clear what should and should not count as a “probabilistic” PL. Over the course of a number of discussions on the topic, I’ve settled on “inferential” PL as describing what is (or, at least what I find) interesting about “probabilistic” PL. I’ve been meaning to write a post about the subject, and hopefully this footnote will remind me to do so.

[2] N.B., the indexing used in that package is what we get if we erase/compactify the universe U. That is: the erasure of U is a singleton set; the erasure of [U] is isomorphic to the Peano numbers; the erasure of [[U] × U] is isomorphic to a list of Peano numbers; etc.

[3] Though at one point I assume we have functions, (:→), just for the sake of an example.

[4] Ideally we’d be able to flatten this type to avoid all the overhead of the linked list implementation. In fact, the entire AST node of (:$) together with its SArgs should be flattened. These nodes have the same general layout as the heap objects in the STG machine: a record with a pointer to the data constructor (i.e., element of the signature) followed by an appropriate number of arguments; and so in principle we ought to be able to implement them directly with a single STG heap object.

winterkoninkje: shadowcrane (clean) (Default)
2015-09-12 01:21 am

Femme erasure: An open letter on the US Trans Survey

Hi NCTE,

I took the US Trans Survey a while back and had some feedback, though I forgot to include it in the survey itself. In particular, my comment is about the gender/identity portion of the survey (question 2.2). It's great that you include a variety of nonbinary identities (fa'afafine, mahu, genderqueer, genderfluid, two-spirit, third gender,...) but I noticed a severe bias in terms of the more binary options. You offer a variety of options for masculine-of-center folks (AG, butch, stud,...) but you offer zero options for feminine-of-center folks. This contributes to the ongoing problem of femme/feminine erasure in feminist and LGBT communities. I identify very strongly as femme, in fact it's one of the few labels I "identify" with— far moreso than I "identify" with trans, fwiw.

While I did write in under the "other" option, I worry that this only serves to contribute to the ongoing erasure and underrepresentation of feminine identities. Having worked on a number of these sorts of surveys, here's a short list of reasons why:

  • Feminine-of-center folks will be undercounted because many will not feel strongly enough to write in.
  • The presentation of specific choices for masculine-of-center identities helps to funnel people towards particular terms, improving their statistical significance; whereas the lack of explicit options for feminine-of-center folks will result in a larger diversity of terms, thus decreasing each term's likelihood of reaching significance.
  • Attempting to correct for the previous point by aggregating all feminine-of-center identities serves to erase the diversity of femme/feminine identities: "femme" forms no more a singular identity than AG/butch/stud/etc forms a singular identity. The distinctions between high femme, hard femme, tomboy femme, etc are just as important as the distinctions between varieties of nonbinary or masculine-of-center identities.

While it is too late now to correct the 2015 survey, I do hope you take this into consideration when choosing how to report your results and when designing future surveys.

winterkoninkje: shadowcrane (clean) (Default)
2015-09-11 11:32 pm
Entry tags:

What do we mean when we say "the Haskell community"?

One of the folks I've chatted with a bunch online and finally got to meet in-person this year was Gershom. Towards the end of the symposium, he mentioned the post I linked to last time about my pulling away from Haskell communities. But the way he phrased it really struck me. And I wanted to comment on that.

I guess the crux of it comes down to, what do we mean when we say "the Haskell community"? What I meant when writing that post over a year ago was the online community of Haskell learners/practitioners (i.e., the folks who dominate spaces like reddit). But what Gershom's comment suggested was the academic community of FP researchers who work on/with Haskell (i.e., the folks who dominate spaces like ICFP). These two communities have always been intertwined, but as Haskell gains popularity they feel more and more distinct.

FWIW, I do still feel welcome as part of the academic community. There are some things I could comment on, sure, but those have more to do (i think) the general issue of being a woman in tech than they do with Haskell per se. Of course, this only underscores the concern of my original post. The free exchange between academics and practitioners was always a big part of what I've loved about the (general) Haskell community. Were not for that exchange, the spark planted by Mark Jones would never have fanned into the flame of my current research. As that free exchange unravels, this pathway from interested novice to researcher is cut off. And that pathway is crucial for the vibrancy of the community, as well as for addressing those general issues of being a minority in tech.

winterkoninkje: shadowcrane (clean) (Default)
2015-09-11 03:36 am

Back home from ICFP

Got back from Vancouver a couple days ago. The return flight was hell, but other than that the trip was pretty good. Got to meet a whole bunch of folks who read my blog (hi!), which was super cool. It always gives me warm fuzzies to know people are actually interested in my stuff. (You'd think I'd get used to it after a while, but no, evidently childhood scars still remain years after developing a solid sense of self-esteem. Go fig.) Of course, now I feel bad about not having written much of late. I have a few posts I've been meaning to write —mostly technical ones—, and I'm thinking I might should try to kick those out as a way to get back into the daily writing habit needed for finishing up my dissertation.

Since handing out my card at ICFP, I've been hacking around on my website. I'm still working on getting my publications/presentations to be properly formatted, and the timestamps in the footers on a couple pages are busted, but other than that I think it's in pretty good shape. I also took part in a keysigning party for the purpose of building a WoT as part of the developing story for how we securely deliver packages in Haskell. My key is up on Keybase as well as on my website (along with all my other contact info).

After a week of great talks, too much drinking, and too little sleep, I met up with a dear friend from undergrad. It's been far far too long since we've had a chance to hang out (alas, he couldn't make the wedding last year), but he's one of those friends you can just fall right back into. It's funny how much can change and yet stay the same. In one of our ambling walks I dragged him into a clothing store —something I never would've done pre-transition. He didn't seem to mind. He just went along like it's the sort of thing we've always done. And it felt to me like the sort of thing we could've always done. Recently he's been ref'ing for roller derby up in Victoria, and after talking about it I'm thinking I might try my hand at it. Sounds like a lot of fun. We have a team in Bloomington, and they're doing a training/recruiting thing, though alas I'll miss it since I'll be in Mountain View on the 14th. I'll see if I can't find some other way to get introduced.

winterkoninkje: shadowcrane (clean) (Default)
2015-08-30 02:07 am

(Re)meeting folks at ICFP

In the spirit of Brent's post, I figure I'll make a public announcement that I'm in Vancouver all week attending HOPE, ICFP, and the Haskell Symposium. I love reconnecting with old friends, as well as meeting new folks. Even if I've met you at past ICFPs, feel free to re-introduce yourself as ...things have changed over the past few years. I know I've been pretty quiet of late on Haskell cafe as well as here, but word on the street is folks still recognize my name around places. So if you want to meet up, leave a comment with when/where to find you, or just look for the tall gal with the blue streak in her hair.

Unlike Brent, and unlike in years past, I might should note that I am looking to "advance my career". As of this fall, I am officially on the market for research and professorship positions. So if you're interested in having a linguistically-minded constructive mathematician help work on your problems, come say hi. For those not attending ICFP, you can check out my professional site; I need to fix my script for generating the publications page, but you can find a brief background/research statement there along with the other usuals like CV, recent projects, and classes taught.

winterkoninkje: shadowcrane (clean) (Default)
2015-07-09 02:45 am

In which, recent and forthcoming events are discussed

These past few weeks I've been hacking up a storm. It's been fun, but I need to take a break. One of the big things I learned last fall is that I really need to take breaks. I was good about it all spring, but this summer I've been slipping into my old ways. Those workaholic ways. And when it gets that way, too often coding begins to feel like ripping out a piece of my soul. Or, not ripping. Purging. Whatever. In any case, not good. I much prefer the euphoric sorts of hacking sprees, where spilling my art out into the world feels more like a blessing, like gift giving, like spilling my heart does. So yeah. If it's not like that, then I need to take a break.

The last couple days I've been watching Sense8, which is amazing. It's been a long time since I've given anything five starts in Netflix. I've been watching some cool stuff, been giving lots of fours, but not fives. So yeah, total five star work. The Wachowskis are amazing. I never got all super into the Matrix like everyone else —I mean the first movie was fun and all— but yeah, between Jupiter Ascending and Sense8, they're just awesome. Should prolly see their rendition of Cloud Atlas; but I dunno if it could really live up to the book.

Speaking of breaks, and furies of activity: I'm flying out to Portland on saturday, will be there for a week. Then, when I get back I'm going to WOLLIC/CoCoNat for a week. And then, towards the end of the following week I start the interview process at Google. Then there's a couple weeks of calm before flying off to ICFP. And after that, I need to dig into the dissertation again. Really, I should be working on it now, but like I said: other coding has been eating at my brain. Really need to get it just squared away and out the door. Can't wait to fly off to Mountain View or wherever else is next in life.

winterkoninkje: shadowcrane (clean) (Default)
2015-06-06 08:50 pm

ANN: bytestring-lexing 0.5.0

bytestring-lexing 0.5.0

The bytestring-lexing package offers extremely efficient bytestring parsers for some common lexemes: namely integral and fractional numbers. In addition, it provides efficient serializers for (some of) the formats it parses.

As of version 0.3.0, bytestring-lexing offers the best-in-show parsers for integral values. (According to the Warp web server's benchmark of parsing the Content-Length field of HTTP headers.) And as of this version (0.5.0) it offers (to my knowledge) the best-in-show parser for fractional/floating numbers.

Changes since 0.4.3 (2013-03-21)

I've completely overhauled the parsers for fractional numbers.

The old Data.ByteString.Lex.Double and Data.ByteString.Lex.Lazy.Double modules have been removed, as has their reliance on Alex as a build tool. I know some users were reluctant to use bytestring-lexing because of that dependency, and forked their own version of bytestring-lexing-0.3.0's integral parsers. This is no longer an issue, and those users are requested to switch over to using bytestring-lexing.

The old modules are replaced by the new Data.ByteString.Lex.Fractional module. This module provides two variants of the primary parsers. The readDecimal and readExponential functions are very simple and should suffice for most users' needs. The readDecimalLimited and readExponentialLimited are variants which take an argument specifying the desired precision limit (in decimal digits). With care, the limited-precision parsers can perform far more efficiently than the unlimited-precision parsers. Performance aside, they can also be used to intentionally restrict the precision of your program's inputs.

Benchmarks

The Criterion output of the benchmark discussed below, can be seen here. The main competitors we compare against are the previous version of bytestring-lexing (which already surpassed text and attoparsec/scientific) and bytestring-read which was the previous best-in-show.

The unlimited-precision parsers provide 3.3× to 3.9× speedup over the readDouble function from bytestring-lexing-0.4.3.3, as well as being polymorphic over all Fractional values. For Float/Double: these functions have essentially the same performance as bytestring-read on reasonable inputs (1.07× to 0.89×), but for inputs which have far more precision than Float/Double can handle these functions are much slower than bytestring-read (0.30× 'speedup'). However, for Rational: these functions provide 1.26× to 1.96× speedup compared to bytestring-read.

The limited-precision parsers do even better, but require some care to use properly. For types with infinite precision (e.g., Rational) we can pass in an 'infinite' limit by passing the length of the input string plus one. For Rational: doing so provides 1.5× speedup over the unlimited-precision parsers (and 1.9× to 3× speedup over bytestring-read), because we can avoid intermediate renormalizations. Whether other unlimited precision types would see the same benefit remains an open question.

For types with inherently limited precision (e.g., Float/Double), we could either pass in an 'infinite' limit or we could pass in the actual inherent limit. For types with inherently limited precision, passing in an 'infinite' limit degrades performance compared to the unlimited-precision parsers (0.51× to 0.8× 'speedup'). Whereas, passing in the actual inherent limit gives 1.3× to 4.5× speedup over the unlimited-precision parsers. They also provide 1.2× to 1.4× speedup over bytestring-read; for a total of 5.1× to 14.4× speedup over bytestring-lexing-0.4.3.3!

Links