It looks like you're new here. If you want to get involved, click one of these buttons!
Code snippet:
// Simply negating the result of e.g. `U::I8` will result in overflow for `std::i8::MIN`. Instead,
// we use the fact that `U: NonZero` by subtracting one from the `U::U8` before negating.
impl<U: Unsigned + NonZero> Integer for NInt<U> {
const I8: i8 = -((U::U8 - 1) as i8) - 1;
const I16: i16 = -((U::U16 - 1) as i16) - 1;
const I32: i32 = -((U::U32 - 1) as i32) - 1;
const I64: i64 = -((U::U64 - 1) as i64) - 1;
#[cfg(feature = "i128")]
const I128: i128 = -((U::U128 - 1) as i128) - 1;
const ISIZE: isize = -((U::USIZE - 1) as isize) - 1;
// snip...
}
(This code excerpt can be found on Github).
Context:
This code snippet is in the Rust programming language. Rust is a lower-level programming language intended to replace C and C++ code, but with additional safety features that allow the Rust compiler to prove that a program will not exhibit certain kinds of bugs before the code is compiled. As part of these safety features, Rust has a robust and complex type system that can catch certain kinds of bugs (e.g., if a function accepts numbers, but is given a string). The specific code above is from a Rust library called typenum, a Rust library that allows for programmers to perform arithmetic computation within types. This allows for certain kinds of behaviors to be enforced while code is being compiled (e.g., you could prove that some code that concatenates two arrays produces an array whose length is equal to the sum of the lengths of the individual arrays). This specific code snippet implements a means of negating a type-level number.
The typenum library is largely concerned with safety---preventing potential logic errors in code at compile-time---and provides as example use cases:
dimensionedwhich does compile-time type checking for arbitrary unit systems andgeneric-arraywhich provides arrays whose length you can generically refer to.
I've always been super fascinated at the genre of "programs that perform type-level computation using language features unintended for that task." There are many examples of this kind of performance in the wild: Brainfuck implemented in the Typescript type system [1,2], Forth implemented with Rust traits [3]. What excites me most about these kinds of projects is their queer (mis)use of simpler language features, ostensibly designed to provide easy-to-reason about guarantees to the programmer. The trait system in Rust is intended to provide folks with certain guarantees about their program---a type that implements a trait has guarantees on what methods it will implement, and what those methods will do. In this case, typenum is participating in queer use of the trait system---type-level computation---but in service of the same goals of the trait system itself: safety and security, to strengthen the compile-time guarantees provided by the language.
In reading this code snippet, I found myself returning to Tara McPherson's articulation of the UNIX operating system as being co-constitutive with race. McPherson notes that UNIX articulates security through modularity---separation of concerns and an atomization of programs, a reflection of the rise of neoliberalism in the 1960s. I would argue that Rust articulates security through abstraction. One of Rust's primary selling points is its zero-cost abstractions: "the ability to move certain behaviors to compile time execution or analysis." [4] The way it achieves guarantees around memory safety and execution time---the borrow-checker---relies on abstraction of the computer's memory model as a series of memory regions (an idea borrowed from the Cyclone language). The trait system being exploited/queered here is a mechanism for abstraction---being able to call methods on a trait without relying on implementation details of that trait. Rust exploits abstraction in service of securitization: guaranteeing that programs will not have data-races, use-after-frees, or runtime type errors.
In the contemporary U.S. American context, queerness is contending with its own kinds of abstraction. In the reactionary conservative imagination, "gender ideology" has become a phantasm, as Judith Butler puts it, into which anything and everything---DEI programs in colleges, drag shows, ethnic studies, trans and queer folks generally existing---can be slotted into. Jasbir Puar reminds us of how homonationalism recruits queerness into projects of nationalist exceptionalism, e.g., the U.S. using protection of queer folks to justify military intervention abroad, thus abstracting the meaning of "queerness" in the same vein as "democracy." These concerns are material to the Rust community itself. On one hand, there are thriving queer subcommunities within the Rust language, and queer folks are able to show up in the Rust community in ways unique to Rust. On the other hand, the security guarantees Rust provides gives it widespread corporate appeal, and Rust has become increasingly used at the companies at the heart of the U.S. American tech oligopoly.
Thus, I'd like to play with what it would mean to say the sentence: "We read Rust as co-constitutive with queerness." I'm curious how we can read the code of typenum as co-constitutive with queerness and its relationship with abstraction: examining the ways in which frameworks of abstraction and securitization are queered in typenum and Rust as an index into the social formations of U.S. American life.
Questions:
How do we feel about these kinds of language feature shenanigans :^)
How can we read programming language design as intertwined with predominant social formations?
Links:
[1] https://github.com/QuiiBz/tsfuck
[2] https://github.com/sno2/bf
[3] https://github.com/Ashymad/fortraith
[4] https://doc.rust-lang.org/beta/embedded-book/static-guarantees/zero-cost-abstractions.html
Comments
Thank you for this very interesting approach to typenum, type systems, Rust, abstraction, and queerness. I've enjoyed engaging with your questions, and I hope that I am not misunderstanding your thinking in my thoughts below.
I am trying to take up this question by thinking carefully through what "co-constitutive" means in this context. I believe that this is the McPherson article in question:
When thinking about "co-constituting," I turn to this passage after McPherson tells the story of two "fragments in time" roughly centered around 1950-1975. Some of her cultural touchstones are briefly mentioned connect to other code previously taken up by the CCS Working Group, for example connection between the Watts uprising of 1965 and
BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agcin the source code for the Apollo 11 Lunar Module's guidence computer (AGC). After focusing on events in what we might call the rise of UNIX (~1963-1974) and the U.S. civil rights movement (~1965-1968) (McPherson pointedly narrates events but does not name periods), she continues:This "two cultures" critique is one of the ones we were thinking about during our first week discussion of "Where is the Critical in Critical Code Studies."
McPherson's concludes that "If, in the 1960s and 1970s, UNIX hardwired an emerging system of covert racism into our mainframes and our minds, then computation responds to culture as much as it controls it." This is based on the argument that the Gramscian "common sense" of 1970s programmers as a community led them to mirror in code the same security logic that "the U.S. [was] widely coming to process race and other forms of difference in more covert registers."
Turning to the example of typenum, I'm thinking about a possible tension in two related ideas: that surprising innovations on simpler language features such as type-checking as productive spaces of "queer (mis)use" on the one hand, and the idea of a type guarantee language as "co-constitutive with queerness" (in a neoliberal sense) on the other. Perhaps there is no tension: you point out that in typenum the type-level computation is "in service of the same goals of the trait system itself: safety and security, to strengthen the compile-time guarantees." Is this a case of Audre Lorde's "The master's tools will never dismantle the master's house"?
Still, a type system as a field of play seems generative to me in a way that doesn't have an easy analog in McPherson's writing on UNIX, which is emphatically not e.g. inspired by productively playful racial imaginaries being suggested by kernel segregation, pipes, or permissions bits. Notably, she reads the role of diversity and the "Rule of Diversity" in early UNIX discourse as following the "tenets of neoliberal multiculturalism" and the "tenets of post-Fordism." In both UNIX and neoliberalism the productive possibilities of diversity are analogously embraced, contained, and rendered safe; this is a feature of the paradigms, not an exception to the rule of secure compartmentalization. Is this the case for Rust, abstraction, type systems, and queerness as well, or does queer mis(use) become liminal or escape the logic of abstraction? Could race and diversity also escape (through) the logic of early UNIX as well?
Play is the question, isn't it? If we read Rust as co-constitutive with queerness in a specifically neoliberal sense (e.g. a logic of safe types specifically or memory abstraction generally culturally mirrors the logic of safely compartmentalized and controlled queer diversity) then how might we narrative the cultural logic of dynamically typed languages such as Python and JavaScript?