They picked a bunch of green peppers the other day, so today we washed and packed them. 23 cases of 45 each, plus an extra 32, plus the bad ones that we threw out, so yeah, well over a thousand, I guess.
More variation in size than I would have liked, given that we’re selling them by count rather than by pound. Some of them were well over a pound, some were less than a half pound, though we stashed most of those for other uses.
I started a new shunting-yard parser implementation. I’ve done it before but I feel like it always gets messy and I’ve never been quite happy with how it ended up.
And one of the worst bits is the way that the different classes of operator interact: infix, prefix, and suffix/postfix/whatever-you-call-it. The basic thing is you’re deciding what the precedence order is between a pair of operators: do you do them in right-to-left or left-to-right order? So three classes times three classes is nine possibilities. I’ve always found it tricky to think about it and I usually make errors.
But today I realized that if you look at the operators as laid out in the source code, you’re just deciding which way the parenthesis faces between the two operators. And if the source structure disallows an value between the operators, then you don’t have a choice: there’s only one way the parenthesis can face.
So you end up with these expression fragments:
* a) * |
* (--a |
* (a++ |
--a) * |
--(--a |
--a)++ |
a++)* |
N/A (needs * between) |
a++)++ |
Eh. Out of context that’s still probably clear as mud. But I think when you’re implementing operator precedence parsing it’s a lot clearer than the ways I’ve been thinking about it…