tim | Recent Entries

Today I stumbled upon "Categorical Exclusions: Exploring Legal Responses to Health Care Discrimination Against Transsexuals" [PDF], a 2002 article in the Columbia Journal of Gender and Law by Kari E. Hong. In my opinion, the most interesting point Hong raises in her discussion of how American law enshrines anti-trans discrimination is about the Americans with Disabilities Act (ADA).

Is being trans a disability? Arguably so, under the ADA's definition of "disability":

"(1) a physical or mental impairment that substantially limits one or more of the major life activities . . .; (2) a record of such impairment; or (3) being regarded as having such an impairment."

Even from the perspective of trans activists who believe the only unpleasant thing about being trans is the marginalization that we experience by cisnormative society (a perspective I don't share), being trans qualifies under clause (3): even trans people who don't believe they have a medical condition, don't believe that "gender dysphoria" or "gender identity disorder" are real things, and don't feel they require medical intervention are regarded as "impaired" by others. Under one definition, being trans means to have one's gender and/or sex not universally recognized as valid. That means that you are regarded as impaired in an area of life that most people consider essential (having a gender and sex that are concordant and unambiguous). So at least by the ADA's standards, being trans is a disability. I don't have a problem with that, since I don't feel the need to perpetuate ableism by holding myself as superior to and apart from people who have disabilities.

Since the ADA makes it illegal for health insurance companies (as well as health care providers) to discriminate on the basis of disability, you might wonder why a significant majority of group health insurance plans in the US (and every individual health insurance plan that I know of) have specific trans exclusion clauses in their policies, which exclude coverage for what is usually -- crudely and non-clinically -- referred to as "sex transformation" or "sex changes". Actually, these clauses exclude coverage for a variety of reconstructive surgeries (mostly on the genitals, chest, or face) when trans people are having them. Often, the policy covers the very same reconstructive surgery for cis people that's excluded for trans people: for example, breast reconstruction for cis women who have had mastectomies due to breast cancer is covered (this is required by federal law), while breast reconstruction for trans women is not.

So according to the ADA, isn't this blatantly illegal discrimination? Well, no, and for that, you can thank Republican senators (at the time) William Armstrong, Orrin Hatch, and Jesse Helms, all of who were involved in introducing a heinous amendment to the ADA:

At the end of the bill, add the following:

Under this act the term `disability' does not include `homosexuality,' `bisexuality,' `transvestism,' `pedophilia,' `transsexualism,' `exhibitionism,' `voyeurism,' `compulsive gambling,' `kleptomania,' or `pyromania,' `gender identity disorders,' current `psychoactive substance use disorders,' current `'psychoactive substance-induced organic mental disorders,' as defined by DSM-III-R which are not the result of medical treatment, or other sexual behavior disorders.'

If you read Hong's article, you can find some of the despicable things that Armstrong and Helms said on the Senate floor that led to the introduction of this amendment. As Hong points out, Armstrong and Helms made no attempt to hide that their antipathy for trans people, pyromaniacs, drug users, and so on had nothing to do with evidence or medical science. I can't help thinking about much more recent controversies over Republicans like Todd Akin, who also made medical claims (that cis women who experience rape can't become pregnant) that are completely contradicted by fact. It's hard not to think that there not only hasn't been progress in the past quarter-century, but that we've gone backwards. While Armstrong's and Helms' ignorant statements could maybe, maybe be excused by the lack of widespread knowledge about and experience with trans people, Akin lacked that excuse for his asinine statements about pregnancy -- not a marginal condition, but one experienced by up to half the human population.

Because nobody in the Senate really gave a shit about trans people (not that I have any reason to think that's changed), the Armstrong-Hatch amendment passed, and continues to be law today. There are other legal bases on which somebody who was denied insurance coverage just for being trans could challenge that decision, but without some significant effort to show that the Armstrong-Hatch amendment violates the Equal Protection clause of the Constitution, the ADA won't be one of them. Then again, it does violate the Equal Protection clause, so you'd think someone would get on that.

Hong's article is ten years old; since then, I've seen very little other writing that explored a potential ADA-based challenge to trans exclusion. Recently, groups like the National Center for Transgender Equality and the Transgender Law Center, as well as writers like Melissa Harris-Perry, have lauded how the Affordable Care Act (ACA) adds additional legal protections for trans people facing health care discrimination. However, I find these celebrations to be premature and totally misleading and harmful, since the ACA in no way addresses the core issue that trans people can be denied medical care that cis people get with no obstacles, simply because we belong to a socially stigmatized group. So long as social stigma affects the kind of health care I can access more than medical necessity does, I won't be celebrating.

Postscript: There's one thing I think Hong is totally off-base about: her assertion that trans kids shouldn't receive medical treatment. If her opinion were policy, at least one person I know probably wouldn't be alive today, and that would be bad, since I prefer her to be around. She seems to confuse reparative therapy for trans kids as practiced by Ken Zucker and supported by his pals entourage Ray Blanchard and J. Michael Bailey, cheerled by Anne Lawrence and Alice Domurat Dreger -- something that is absolutely harmful and unethical -- with treating trans kids by letting them be the gender they are. These two modalities are about as similar as antifreeze and ginger ale, but Hong seems to fall for the harmful misconception (allow me: cisconception?) that medical treatment for trans kids amounts to forcing gender roles on them. That couldn't be further from the truth, since denying medical treatment is an attempt to force a gender role on a trans child: the gender role the child was arbitrarily and coercively assigned at birth. When it comes to adults, though, I find Hong's arguments pretty sound (aside from some of the language -- like the self-contradictory phrase "biological gender" -- which reflects the standards of the time).

I'm still chugging along trying to get my code to eliminate match checks checked in, little by little. My list of examples of incomplete matches in the compiler is growing.

I'm trying to wait until all the match checks are gone to check in the code that removes support for the construct, rather than check it all in in one big patch, so that means a laborious process of checking out a new temporary branch that's a copy of my working branch; git reset --softing all the match-check-related changes, picking and committing the few files I want to keep this time, and doing git reset --hard to get rid of the other changes. And then running make check... and waiting... so... long... for it to finish. (And then, usually, having to pull changes and rebase because git tells me pushing wouldn't be a fast-forward.) But I don't want to break the build.

Not much to say about it, just wishing we had refinement types. Or that I could just go ahead and implement them. (It will likely be more character-building for me to rewrite metadata and rationalize the dependency situation, though.)

Today, I conquered git submodules in order to push my first change to Servo!

Then I went back to trying to kill match check. I'm learning an important lesson about staging my changes better, since while the whole thing passes tests now (!) it's a lot of tedious work to separate the changes to the compiler that break match check, the changes to everything that remove uses of match check, and the cases where I left myself a little comment saying "improve this" that I want to try to improve before checking in. Next time I'm removing a feature, I'll remove uses of it first, *then* remove support for it.

Today: hacked on Servo for the first time! Servo is the browser prototype implemented in Rust that we're working on. As a first bug, I implemented the JavaScript alert function. But GLUT doesn't support modal dialogs, so instead of popping up a dialog, it just prints the message to the console. Still, this required quite a bit of doing; it also required duplicating some code to add a global Window object, but I wasn't able to factor it out because doing so triggered a number of compiler bugs. I was a bad person and didn't try to minimize test cases for the bugs, because I just wanted to get something ready to check in before leaving for the day. However, I wasn't even able to get something ready to check in, because of rebasing being argh.

So that was that. Tomorrow, hopefully getting my code checked in. And sometime this week, responding to more Bugzilla feedback so that my Ionmonkey patch can hopefully land sometime, and completing the killing of match check with fire.

Responding to second round of feedback on my Ionmonkey project: done! Now with five patches where one would do ;-) (Somewhat reassuringly, when I implemented the test cases that Jason suggested, not all of them worked the first time -- in particular, I had to change toString() for functions to pretty-print generators as function*.)

(This time I finished with that at 4:15PM rather than 10:15, which is good.)

In other news, I tried to make a snapshot, and have not succeeded so far since the past few days have been very sad days for our incoming branch and there have been many broken builds to get through before getting to the snapshot build in the queue. Plus, the Linux bot apparently got wedged trying to run valgrind on something, or at least, it ran for more than ten minutes before I killed the process. So now I'm just waiting for the FreeBSD bot to finish running, and I can push a new snapshot that fixes a trait-related bug I found, which means I can push a change to the core::num library that means one less FIXME in the compiler... oh, the slow progress of compiler work.

Back to removing match check... which is currently blocked on the yak-shave that I mentioned before, which is causing mysterious assertion failures even after rewriting the change from scratch. It seems to be happening in pretty-printer code that the macro-expander is calling, which means it's something I don't want to deal with. Maybe I'll just scrap that change for now and take the easy way out (inserting more failure cases) so I can make progress).

I took a break after writing the paragraph about the snapshot, and in the meantime, the snapshot finished building and I got it, along with the traits change, checked in. And science marches on.

I worked on purging match checks (non-exhaustive matches) from the compiler, but I ended up on what turned out to be a pretty involved tangent. Perhaps I should have resisted the temptation to refactor code and should have instead just added lots of _ => fail; cases. But it pains me to see places where the AST data type could easily ("easily") be changed to not make junk representable.

The refactor in this case is that there were expr_loop_body (representing the body of a Rust for loop) and expr_do_body (representing the body of a Rust do expression, which, by the way, is nothing like a Haskell do expression) variants in the AST where the contents were (according to its type) expr in both cases, but there was an unstated invariant that the contained expr had to be built with the expr_fn_block variant. Obviously, the Right Thing was to replace those three variants with a single expr_fn_block variant, one of whose components is a flag saying whether it appears inside a for, inside a do or neither. (Of course, now that I've said that, one of my colleagues will tell me that there was a good reason for the original type definition ;-)

But, as these things always seem to go, I broke something in a very obscure way (possibly by causing trans to treat a do body like a regular function block, or something) and that manifested itself as wrong code being generated, and thus, assertion failures tripping. (Wrong-code is my least favorite compiler failure mode.)

Meanwhile, I also worked on a FIXME bug that I started last week while looking at references to FIXMEs that had been closed in the meantime. I tried changing the standard library num trait to make its from_int method static (sensibly enough), which tripped a bug in the compiler related to typechecking traits. I fixed that, but needed a new snapshot to make any changes, and then the makefile infrastructure that allows building with a local snapshot seemed not to work, and I can't build a real snapshot since the build is currently broken for other reasons... and so it goes. But at least I checked in something

I spent today working some more on that IonMonkey project. I actually got Bugzilla feedback on it very promptly, but I do not move that promptly.

There's very little interesting to say about it, just fixing style nits and learning more about Mercurial patch queues (which I have to admit are pretty neat) so I could split up my monolithic patch into separate test and non-test patches. Oh, and adding some #ifdefs to make the patch backwards-compatible (a little detail I forgot about). That's always ~~frightening~~fun.

I'll finish this up on Tuesday (mostly what's left is just adding test cases), but on Monday I want to get some more done on removing match check, for great justice!

I closed #2735, which had to do with how

let _ = e;

and

e;

can have different semantics in Rust. As you might guess, "_" effectively means "I'm never going to use this, so just give it a name I can't refer to." (Left-hand sides of let decls, by the way, can be any irrefutable pattern.) So why would they be different?

( Read more... )

I keep putting off this dependency graph project. I thought that faster compile times (and less mental context-switching for me) would be enough motivation, but I guess not; I keep wanting to bite off smaller chunks of work to deal with. Smaller chunks seems safer.

I finished fixing #3099 today, which was because the name resolution pass wasn't checking for multiple items with the same name. So you could declare two functions in the same scope, both called a, and one of them would just be silently ignored. That's not good, so I fixed resolve to error out in that case. This was only non-straightforward because we have several different namespaces (modules, types, values, and implementations) and you can re-declare the same name in a different namespace, just not in the same one (which is what "namespace" usually means). So I had to make sure not to error out when the names were in different namespaces, but otherwise, the machinery was already all there to fix this. Also, I was in the pleasant situation of already having done most of the work for this last week, and the first time I tried running the tests today was the first time it actually worked. That's always nice. ( Read more... )

Because I'm having a few moments of emo and angst about the difficulty of understanding Rust code that's recently been rewritten, as well as the eventual fate of seemingly every major project I undertake, instead of writing a daily blog post today I'm going to talk about something different. (After all, my blog is on Dreamwidth, not LiveJournal, so emo and angst shouldn't be the order of the day.)

I went to a Mozilla intern's final research talk today. It was a good talk, covering some impressive work. Here are some hints for people attending research talks. Actually, they're more like requirements than hints.

1. If the speaker answers a question in a way that you think is naïve, consider that you may have misunderstood what they said. It is always possible that you are wrong, and that what you think was an assertion of fact was actually intended as a hypothetical, simplifying assumption that the speaker does not actually think is true. Under no circumstances should you burst out laughing. Laughter has the tendency to get the rest of the room laughing too, whether or not they actually understood the reason for the laughter. At any rate, laughing at a speaker is really not appropriate under any circumstances unless they have just told a funny joke.

Even if you are friends with the speaker and think that your laughter is appropriate given the terms of your relationship, not everybody else in the audience knows that. Your behavior sets an example: in this case, that it's okay to laugh at people. It has an effect. Try to make it a good one.

2. If you have something snarky to say about the contents of a talk, say it to your friend afterward. Write it down, if that helps. Don't say it out loud during the talk, even if you think no one else can hear you. Always assume you're sitting next to the lead developer on the project that the speaker is speaking about, and that they have excellent hearing.

Respecting people isn't hard, but when people do stuff like this, it fosters a disrespectful culture. It also creates an environment where people are afraid to speak up, make mistakes, and be wrong. Everyone should be able to experiment, take risks, and express bold opinions without fear of being made fun of for not knowing something. When somebody needs to boost themself up at another person's expense, I always assume that they're deathly insecure and afraid of having their own ignorance exposed. But there's no need to be afraid. Building software is difficult, and nobody is naturally good at it. We can all build an environment where no one is afraid to expose their weaknesses -- which is to say, where no one is afraid to learn and grow.

I'm taking time off during a workday to write this, but damn it, if I don't, I'm just going to explode here.

About midway through 2011, when it looked like there was a good chance I was staying in California for a while, I went to get a California's driver's license. I had had a CA license before, using my former legal name. This time, I checked off male as my gender, since I had my passport with me (which I'd already had corrected) and nobody was likely to question that I was male. The worker at the DMV looked up my old records when I said I'd previously had a driver's license in CA (I didn't mention that my name was different, since he didn't ask) but he didn't find anything. A week later or so I got a new CA license in the mail.

An entire year later, I got a letter in the mail from the DMV asking me to submit a DL-329 form to change my gender, with a threat that my driver's license would be invalidated three weeks from the date of the letter if I didn't do this. (They took a year to figure out they'd made a mistake, but gave me three weeks to address the issue.) I called the number on the letter, and talked to a person who works for the Records and Security Division. She explained that because there were two entries for people with the same Social Security number but different names and genders (my old name and my new name), that looked as if there were two people using the same Social Security number. To prove that these were the same person, I sent them a copy of my legal name change decree from five years ago, as well as my passport. That was about a month ago.

Since I'm buying a car, I wanted to check that my license was still valid, so I called the person I talked to before again. She said that she had received the documents, but if I didn't submit a DL-329 form, the DMV would invalidate my current license and I would have to go get a new license with an 'F' gender marker. I asked her if it was correct that she was asking me to carry a driver's license that says I'm female, and a passport that says I'm male, and she said that was correct. I asked how she expected me to prove that I should have an 'F' gender marker, since when I went to the DMV the worker would clearly see that I present as male. She said I should bring a copy of my birth certificate. I asked if it's correct that California disregards federal law by requiring people to have a different gender on their ID than the gender on their federal government ID. She said yes.

I am not up for debating why I don't want to fill in the DL-329 form and I will delete any comments that try to argue with me about this. I don't agree with the idea that either the motor vehicle registry or a doctor is more qualified to assess whether my "demeanor" is "male" or "female" than I am. I also don't know what it means to have a "male" or "female" demeanor. If I put barrettes in my hair, does that make my demeanor "female"? I don't think the DMV or anyone who was involved in making the law that underlies this form knows what it means to have a "male" or "female" demeanor, either.

Besides that, it's sex discrimination to subject trans people to a process of having their "demeanor" assessed as male or female just to be able to drive a car (and what if your demeanor is neither male nor female?), when cis people aren't required to prove what their gender is or get a doctor's signature to prove their demeanor is male or female.

So, now I have the options of either not only not driving, but not having any government ID other than my passport; or turning in my current driver's license in exchange for one with the wrong gender on it. I honestly don't understand why California feels the need to have a definition of what gender I am that's different from the federal government's definition. (Yeah, I know legal gender doesn't actually exist and is just a name to cover up a process of institutionalized bullying -- that's sort of the point.)

I don't see why I can't just keep my driver's license the way it is, especially given that having the correct gender on my license for the past year hasn't harmed anyone.

I would like suggestions, but "ask _____", where the blank is filled in with any well-known trans rights organization, is not going to cut it. Sorry. All the organizations that I know of appear to think that the current process is just fine and there's nothing wrong with making trans people, but not cis people, fill out a DL-329 form to get correct ID. If you have actual evidence that this isn't so, please share, but otherwise, yes, it has already occurred to me to talk to whatever organization you're thinking of, and no, I don't think that's going to work. Many trans people are happy with the current system of gatekeeping and don't see a reason to change that. I just don't see why anyone should have to fill out a demeaning and dehumanizing form just to be able to drive a car or, less than that, write a check or buy liquor. And as I said, I'm not up for debating this, only for receiving practical suggestions about solving the problem at hand. As such, all comments are screened.

I'm also wondering what happens if I correct my birth certificate before going to the DMV, and thus have no documentation left to show that "proves" I'm female (let's not talk about the absurdity to have to prove something that's false in order to get a driver's license). Unfortunately, Massachusetts's requirements involve proof of what they erroneously call "sex reassignment surgery", and while I happen to have that, I don't want to tacitly approve of a system that says that having surgery changes people's sex or gender, which it doesn't do. Then again, is it a lesser evil to supply proof of surgery in order to get a correct birth certificate that I can then use to buffalo California and their unarguably more objectionable rules?

It's about 7:30 PM and I have another two or three hours to go before the northbound Coast Starlight train I'm on gets to San José. I've done all of the work, and working on the other (much huger) blog post in progress that I'm working on, that I can stand for today. You know what that means, right? It's Surgery TMI O'Clock!

Like with my first surgery post, some disclaimers apply:

I like to be open even about things many people consider private, and that means I'm okay with writing about intimate details about my body and my sexuality in public. I'm okay with sharing these details with anyone who might stumble upon them. But you may not be comfortable with reading about them. I'm expecting this will mainly apply to people who know me in particular contexts.
Besides the sexy stuff in here, there's also stuff that's kind of gross, so if you're made easily queasy by blood 'n gore, you might not want to read it either. Seriously, if you don't like reading about pain and some of the grosser things bodies do, don't read it.
Just because I'm sharing these details doesn't mean it's okay to ask any other trans person about surgery they've had, surgery you think they may have had, surgery you think they should have, anything else about surgery, or any intimate details about their bodies that you wouldn't ask someone who wasn't trans who you knew only casually. So don't do that! We're not all alike, and I am not going to be the one who gives any cis people an excuse to ask other trans people invasive questions. In fact, there are a lot of situation in which I don't want to discuss the contents of this post, even with people who I'm comfortable having read it: in the office, in church, on VTA Light Rail, and so on. So use the same judgment you'd use when bringing up any other sensitive topic.

If this post doesn't provide TMI about how I relate to my body and about what makes me tick, sexually, then I'll have left something out that I meant to put in, and you'd better nag me about it. It's up to you whether you want to read or not, and so you can decide for yourself, here's a cut tag.

( Read more... )

Dear world (including my co-workers): please remind me to not work remote ever if I can avoid it! At least not until rustc gets significantly faster. The reason is that when I have two laptops, I can work on something else while I'm waiting for a build, whereas with only one, I get to... stare into space for 5-ish minutes every time I make a change. "I can just work on the train" only works if I bring two laptops with me. And that just gets awkward. (Yes, I worked all day today on a train going from Los Angeles to San José. Actually, I'm still not even in Paso Robles yet. We have slow trains in my country.)

With that out of my system, today after finishing bug triage (not very eventful; I learned that in the 1500-2000 range, there are a lot of legitimately hard and unfixed bugs, many of which are more like feature requests but not all) I wanted to fix as many open ICEs as I can. There aren't that many of them. Issue 3091 was pretty quick. I just had to make region pointers not a scalar type (they're really not scalar, since they have sub-structure that's visible in the language) and then change all the code that was casting pointers to region pointers to, well, not do that. (This happened only once in the core libs and in a few test cases.) As with so many things (well, not really that many things, I hope) the solution was to introduce library functions that wrap unsafe::reinterpret_cast (which is the equivalent of Haskell's unsafeCoerce). I'm quite proud of the name I came up with for the function that takes an &T to a *T: assimilate (because it makes the pointer forget its region).

( Cut for length )

So, I had stage II of my surgery (link goes directly to probably-TMI details; do not pass Go, do not collect $200) and everything went fine, except that, unfortunately, there will be a stage III. I meant to do a post-surgery summary post, and then horrible complications happened, and I wanted even more to write a post explaining what happened and why I had no regrets anyway... but anyway, that hasn't happened yet. But, I still want to write up everything that happened post-first-surgery!

This is not that post, though. So, I had IV sedation, which means you're sort-of-conscious during surgery but can't really feel anything. You're not supposed to remember things that happened while you were sedated, either, but I do, both from this time and the previous one. This time I was pretty awake for what I'd guess was the last 20 minutes of the surgery, not feeling any pain or anything, but able to listen to my surgeon talking to the nurses. They were talking about Portland for whatever reason and the doctor was describing a poster he saw when he first moved to Portland, and how it showed this guy standing with his back to the camera while opening his trench coat (which, it was implied, there was nothing under it) to a sculpture. And also, the guy was the mayor of Portland at one point. Then he said what the caption of the photo was. I don't remember what he said, but it was wrong. So I said "actually, it said 'Expose Yourself to Art'" and he was like "oh, you're right". (Possibly after that they gave me more drugs, I don't know :P)

Moral of story: I won't pass up the opportunity to correct someone who is wrong, even while they're literally operating on me :P (It's this poster.)

Today: a short day, since staying at work till 11 PM, then taking the bus home, resulted in waking up at 12:30 PM and various other silliness. Not feeling like I'm doing that well at being an adult at the moment.

Today, I was planning to work more on dependencies, but issue 3021 caught my eye. The fix was easy, or so it seemed: resolve was treating impl methods like a "normal function" (which may capture variables defined in its enclosing scope) rather than an "opaque function" (which may not). Closures are normal functions, while function items (declared with fn) are considered opaque. Impl methods should be treated the same way as function items. That was a one-line fix, and allowed this test case to pass. I realized the same fix should apply to class methods and trait methods, as well. The problem is that then, a ty param bound by a class (or impl or trait) gets considered an upvar, and then class methods can't refer to it. Which is to say, this code should be accepted: ( Read more... )

Oh frabjous day! I submitted a patch with my changes to the IonMonkey front-end. Looking at the patch, it seems like such a small change, and yet it took me a lot of time to learn to deal with the code base / C++ / Mercurial -- hence the period of a couple months in between starting working on this and now.

Fortunately, building gcc 4.2 worked, so I spent most of today reconciling my changes with the updated version of the front-end. Eventually, all of the tests passed except a few, and those were a few that I wasn't going to fix (two that seemed to be failing for reasons unrelated to my changes, and two that failed because they were using new Function() to create generators -- it's not clear what the syntax should be for that now, or if it should be allowed; I'll leave that for someone else to decide).

I'm also not really sure why this had to take all day, gosh (actually, an 11-hour day). That doesn't matter, though, because it's done (at least up to receiving review for it). And tomorrow I work on Rust again.

Months ago, my overlords and I decided that I was going to spend some time working on something besides Rust. That something ended up involving generators and IonMonkey. It might seem strange for me to work on a JavaScript engine, since I've barely written a line of JavaScript in my life. (Unless you count a job I used to have once where I wrote a little bit of ActionScript. It was better than you might think.) And it is; that's why I eventually decided not to continue working on this project.

(I wasn't familiar with generators before this. It turns out they're what you do when you want to write functions that operate over aggregate data without actually building up intermediate data structures -- such as when you're working in a language whose compiler doesn't do deforestation, such as almost all of them. Rather than relying on the compiler to do shortcut deforestation like you might do in Haskell, generators let you write producers and consumers without the pesky intermediate data structures in between. Or at least that's how I understand them.) ( Read more... )

I got a simple, not-very-smart version of dependency graph generation working, just for types. Here's an example: ( Cut since not everyone likes to look at nodes and edges )

I haven't been writing anything in a while. Honestly, I've been experiencing burnout. It's not that I've been working too hard or anything like that; just that when a colleague tells you "we don't want you around", it's harder to convince yourself to go to work in the morning, or even in the afternoon.

But I should talk about the new and exciting thing I'm working on. The Rust compiler is slow, and while there are any number of reasons for that, one of them is that it recompiles the entire crate every time you change any item, even in a way that's unobservable by any code that depends on the item. Compilers like GHC, with its --make mode, and SML/NJ, with its compilation manager, have been doing incremental recompilation for a long time, so there's no good excuse for us not to do the same for Rust. Incremental recompilation means that the compiler automatically determines dependencies between declared functions, and avoids recompiling files if they haven't changed since the last build and if nothing they depend on has changed either. For example, if I added a #debug statement to the body of a Rust function and made no other changes, it would be safe to recompile only the code for that function.

That sounds easy enough, but ( Of course it's not! )

The first place to look in determining the scope of harassment law, of course, is the legal definition of "harassment." Speech can be punished as workplace harassment if it's

"severe or pervasive" enough to
create a "hostile or abusive work environment"
based on race, religion, sex, national origin, age, disability (including obesity), military membership or veteran status, or, in some jurisdictions, sexual orientation, marital status, transsexualism [sic] or cross-dressing, political affiliation, criminal record, prior psychiatric treatment, occupation, citizenship status, personal appearance, "matriculation," tobacco use outside work, Appalachian origin, receipt of public assistance, or dishonorable discharge from the military
for the plaintiff and for a reasonable person.

Note what the definition does not require. It does not require that the speech consist of obscenity or fighting words or threats or other constitutionally unprotected statements. It does not require that the speech be profanity or pornography, which some have considered "low value." Under the definition, it is eminently possible for political, religious, or social commentary, or "legitimate" art, to be punished [18].

[...]

[18] The definition also does not require that the speech take place in the workplace; even speech outside the workplace can be considered if it creates a hostile environment at work. See Intlekofer v. Turnage, 973 F.2d 773, 775 (9th Cir. 1992) (relying in part on a coworker "telephoning [Intlekofer] at her home" to support a hostile environment claim); Bersie v. Zycad Corp., 399 N.W.2d 141, 143, 146 (Minn. Ct. App. 1987) (relying in part on a coworker "calling [Bersie] at home" to conclude that plaintiff had made a prima facie showing of harassment, expressly applying Vinson); cf. Bartlett v. United States, 835 F. Supp. 1246, 1262 (E.D. Wash. 1993) (finding that two instances of sexually suggestive conduct, including "[p]laintiff receiv[ing] a sexually explicit card at her home from a coworker," did not rise to the level of sexual harassment, but not even hinting that the card was somehow categorically disqualified because it was received outside the workplace); Myer-Dupuis v. Thomson Newspapers, No. 2:95-CV-133 (W.D. Mich. May 9, 1996), reported in Mich. Law. Wkly., May 27, 1996, at 12A. These cases are eminently consistent with the harassment definition given by the Supreme Court: It's quite plausible that speech by coworkers outside the workplace may create a hostile environment within the workplace.

-- Eugene Volokh, 'What Speech Does "Hostile Work Environment" Harassment Law Restrict?'

Tim's journal

Taking metaphors too far since 1995

William L. Armstrong, Orrin Hatch, and Jesse Helms: The Reason Why We Can't Have Nice Things

TMI: Slow progress

TMI: In brief

TMI: Servo hacking

TMI: Trait(orous)

TMI: Yak-shaving

TMI: More Not-Rust

TMI: Exhausting all the possibilities

TMI: It's always in the last place you look

TMI: Research Talk Etiquette

Why does California want me to have government ID that says I'm both male and female?

Actually TMI, unlike my research posts: Volume 2 of the Saga of My Crotch

TMI: Back from the outer realms (aka Arizona)

Funny Surgery Stories

TMI: Unresolved issues

TMI: No, this was not a hazing ritual

TMI: Not Rust

TMI: Pictures - something my work day doesn't usually involve

TMI: Tired of Swordfighting

'The Formal Definition of "Harassment"'

Profile

November 2021

Links

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags