Standard forensics
My life mutates and evolves, its vines clinging to the clay, cutting grooves in no particular pattern but gradually giving me form. Watching its progress is curious; are those tendrils so unlike the roots of these trees? Well, anyway.
(Cat and I) are doing well. She's been away for most of a month, looking after her mother, which is as long as we've been separated since the summer I spent interning at Apple. It's quite different to be the one at home; the residue of a second life surrounds you, temporarily set aside, and you externalize a sort of animist longing onto it all, the idle unopened letters, the chair neurotically checking the calendar, the book on the couch holding a patient seance. The vigil will be over tomorrow, but it seems right to document their efforts.
I was actually going to meet her there, in New York, to go to her cousin's wedding, but it was this last weekend, and there was no wedding, or at least there was no reception, or no cocktail party, or no whatever-it-was-planned-to-be that day, Saturday, before the expected rain washed those plans down to meet the storm. So now I have most of a ticket and no flight. It was going to be a break, a small vacation, even if most of it was to be on airplanes, and I replaced it with work, which was not well-chosen on my part; but I will try to make up for that this next weekend, I think.
Work continues to be quite interesting, and not just in the very dry way that I can find interest in nested formalism, but also in a spate of projects afoot, most of which I cannot discuss, of course. But I do finally find myself in the position of being able to point to something already done and say, Aha, you know, this automatic reference counting that was added to Objective-C, I did that. I did... well, I suppose I did both the principal language design and the main implementation in the compiler, although I had a number of collaborators on both, and there were endless meetings about it, including quite a number above my head. But there, a feature that is not quite so esoteric as "access control" or "exceptions".
I do have something esoteric to go on and on about, though. :)
In C, if you declare a variable, you can then write that name as an expression. That expression is an l-value, meaning the result of the expression identifies a place in memory where a value is stored; it's so called because it's valid on the left side of an assignment. In most places you would write an expression, the l-value is further converted to an r-value, meaning the result of the expression is an actual value, namely the value currently stored in that place in memory. This "value kind" is just as much a part of the type judgement on expressions as the formal type.
For the most part, there isn't much room for latitude in language design about all this: whether an lvalue-to-rvalue conversion occurs depends on the operation being done to the result. There is one exception, though: if the result of an expression is syntactically ignored, should the conversion happen or not? Well, it doesn't normally matter: implementations are generally free not to do operations they don't need to do. However, an l-value can be volatile, meaning you have to do exactly the operations on described by the formal model. (This is the C/C++ definition of volatile; Java's is quite different and much more useful)
Anyway, for various historical reasons C and C++ actually have completely different takes on this. In C, if you have a statement consisting of an expression whose result is an l-value, you always do lvalue-to-rvalue conversion on that; and in C++, you never do. It's been that way for, oh, twenty years or so; it's a bit silly, but it's done. Right? No. Early last year, twelve years into the drafting process of the latest C++ standard, someone actually pointed this out to the committee; and then early this year, the committee finally got around to considering it; and lo, they decided to change the behavior, so that ignored volatile l-values arising from certain syntactic forms (essentially, the forms that can yield l-values in C) would always henceforth undergo lvalue-to-rvalue conversion. So this is progress, of a sort, if you don't mind breaking strict source compatibility.
Of course, they've completely fouled up the new wording in the standard, such that in about eighty words there are (as I've counted so far) four different judgement calls you have to make about their intent. This is pretty standard for C++, which is sometimes as bad as the law in terms of how much legislative history you have to read to divine an often scattered and inattentive purpose, and possibly also in terms of how remote it is from any chance of improving anyone's life.
But at some point, probably soon, one of us will make those judgements and implement the new rule, maybe only in C++11 mode to preserve strict source compatibility, and the language will creak slowly forward on its axles with either one fewer wart or one more, depending on how you see it.
Anyhow, that is one small aspect of the life of a compiler engineer.
(Cat and I) are doing well. She's been away for most of a month, looking after her mother, which is as long as we've been separated since the summer I spent interning at Apple. It's quite different to be the one at home; the residue of a second life surrounds you, temporarily set aside, and you externalize a sort of animist longing onto it all, the idle unopened letters, the chair neurotically checking the calendar, the book on the couch holding a patient seance. The vigil will be over tomorrow, but it seems right to document their efforts.
I was actually going to meet her there, in New York, to go to her cousin's wedding, but it was this last weekend, and there was no wedding, or at least there was no reception, or no cocktail party, or no whatever-it-was-planned-to-be that day, Saturday, before the expected rain washed those plans down to meet the storm. So now I have most of a ticket and no flight. It was going to be a break, a small vacation, even if most of it was to be on airplanes, and I replaced it with work, which was not well-chosen on my part; but I will try to make up for that this next weekend, I think.
Work continues to be quite interesting, and not just in the very dry way that I can find interest in nested formalism, but also in a spate of projects afoot, most of which I cannot discuss, of course. But I do finally find myself in the position of being able to point to something already done and say, Aha, you know, this automatic reference counting that was added to Objective-C, I did that. I did... well, I suppose I did both the principal language design and the main implementation in the compiler, although I had a number of collaborators on both, and there were endless meetings about it, including quite a number above my head. But there, a feature that is not quite so esoteric as "access control" or "exceptions".
I do have something esoteric to go on and on about, though. :)
In C, if you declare a variable, you can then write that name as an expression. That expression is an l-value, meaning the result of the expression identifies a place in memory where a value is stored; it's so called because it's valid on the left side of an assignment. In most places you would write an expression, the l-value is further converted to an r-value, meaning the result of the expression is an actual value, namely the value currently stored in that place in memory. This "value kind" is just as much a part of the type judgement on expressions as the formal type.
For the most part, there isn't much room for latitude in language design about all this: whether an lvalue-to-rvalue conversion occurs depends on the operation being done to the result. There is one exception, though: if the result of an expression is syntactically ignored, should the conversion happen or not? Well, it doesn't normally matter: implementations are generally free not to do operations they don't need to do. However, an l-value can be volatile, meaning you have to do exactly the operations on described by the formal model. (This is the C/C++ definition of volatile; Java's is quite different and much more useful)
Anyway, for various historical reasons C and C++ actually have completely different takes on this. In C, if you have a statement consisting of an expression whose result is an l-value, you always do lvalue-to-rvalue conversion on that; and in C++, you never do. It's been that way for, oh, twenty years or so; it's a bit silly, but it's done. Right? No. Early last year, twelve years into the drafting process of the latest C++ standard, someone actually pointed this out to the committee; and then early this year, the committee finally got around to considering it; and lo, they decided to change the behavior, so that ignored volatile l-values arising from certain syntactic forms (essentially, the forms that can yield l-values in C) would always henceforth undergo lvalue-to-rvalue conversion. So this is progress, of a sort, if you don't mind breaking strict source compatibility.
Of course, they've completely fouled up the new wording in the standard, such that in about eighty words there are (as I've counted so far) four different judgement calls you have to make about their intent. This is pretty standard for C++, which is sometimes as bad as the law in terms of how much legislative history you have to read to divine an often scattered and inattentive purpose, and possibly also in terms of how remote it is from any chance of improving anyone's life.
But at some point, probably soon, one of us will make those judgements and implement the new rule, maybe only in C++11 mode to preserve strict source compatibility, and the language will creak slowly forward on its axles with either one fewer wart or one more, depending on how you see it.
Anyhow, that is one small aspect of the life of a compiler engineer.