johnsfine wrote:I'm a bit scared of that whole mechanism for changing variable values on the fly, but I'm not saying I disagree with it. The first/middle/last pattern is certainly common, so I understand making that the directly supported form. But the semantics for your support of toggle per keypress feel strange. I can guess what you might do for toggle per frame (which also exists) but that also feels ugly.
I take it you mean the RC5 example of toggle per keypress:
{36k,msb,889}<1,-1|-1,1>(T=T^1,(1:1,~F:1:6,T:1,D:5,F:6,^114m)+)
One can use T=T+1 instead of T=T^1, and indeed this better reflects the behaviour of the IR engine. Even T+=1 if we allow that C++ notation. Are these any better? I can't actually see any strangeness in the logic, only in the notation. Toggle per frame would be
{36k,msb,889}<1,-1|-1,1>(T+=1,1:1,~F:1:6,T:1,D:5,F:6,^114m)+
or whatever notation one prefers for the incrementation.
I can't tell whether you want to drop A:B:C and A::C notation from expressions, or whether you just wanted to demonstrate there is an alternate way of getting the same values. I think the use of that syntax for two related but different meanings inside/outside of expressions works well. When specifying which bit fields contribute where to any complex checksum, I think that notation is much clearer than dividing and masking.
I do want to drop the A:B:C and A::C notation from expressions. Your 2003 postings offered A::3 as an alternative to A>>3 but A*8 as an alternative to A<<3. Not exactly symmetrical, which is why I suggested A/8 and A*8 for these expressions. I dislike A:B:C and A::C for several reasons. One is that I think it difficult enough anyway to get across the concept that these are bit sequences, not numbers, in IRstreams without then having to say that after all, they sometimes are numbers. And presumably they can be both in the same item, for instance the bitfield F: (X:2) in an IRstream (I don't mean the space after the first colon, but without it the system turns it into a smiley!). Artificial, perhaps, but it would be valid notation and meaning something totally different from F:X:2. On top of all this, I see a potential ambiguity. What is the value of 11:3 when the protocol has default lsb ordering? 11 in binary is 1011, so is the binary value 110 (as the bit sequence would be 1 1 0) or 011 (the value that we converted into a bit sequence)?
What is my preferred resolution? To allow the << and >> shift operators. I don't know why you are opposed to them, or at least were so in 2003.
I don't know if it would ever get used, but I was hoping for a bit more recursive similarity between defining the body of an irstream and defining values in a bit spec. I do realize I made it quite hard for a traditional parser to distinguish an expression from an IRstream. I hope I didn't make it too hard and maybe allowing either in Bitspec item would make it too hard.
I agree with you in principle, and I started out with that idea, if I understand you correctly. But whenever I tried to write a formal syntax it finished up allowing things like
<1,-2,<3,-4|5,-6>(D:2)+|7,-8>
which horrified me, and would still do so even without the repeat! Is it just the way the syntax is expressed that you would like to look more recursive, or are there constructions you want to allow that currently my syntax doesn't allow?
I had something different in mind for when you convert bit sequences to duration sequences, which I think might be unambiguous across some stranger uses. I would convert from bits to durations every time you get enough bits. Imagine something silly such as:
<1,-1|2,-1|3,-1|4,-1>(<A:3|B:3>(F:5),D:7,1,^999)
The boundaries are all strange, but unambiguous. Each bit of F turns into 3 bits of the outer spec. Whenever you have two bits of the outer spec you can convert them to durations. So even numbered bits of F end with a left over outer bit. F generates 7 outer bit pairs with a bit left over. Since D has an odd number of bits, it all works out.
If you hit a duration instead of a bit when you have part of a multi-bit left over, that would be an error. When the spec for a multi bit goes out of scope, it would be an error for part of a multi bit to be left over. But otherwise the partial multi bit should just set across various scope endings until it can be consumed.
Yes, I quite like it. At present I have the semantics working from the outside inward in translating the content of bitspecs and from the inside outward when translating that of IRstreams. This makes it more consistent, everything going from the inside outward. To make sure I understand, if F:5 is the bit sequence 1 1 0 0 1, you apply the <A:3|B:3> without first evaluating its elements, so the whole thing becomes
<1,-1|2,-1|3,-1|4,-1>(B:3,B:3,A:3,A:3,B:3,D:7,1,^999)
which gives 22 bits to translate by the outer bitspec.
Also, I don't think we should require the power of two in the bit spec. If you gave only 10 bitspec items, then you are grouping 4 bits. Using any of the 6 missing bit patterns would be the error. Simply defining the bitspec with ten items should not be.
I wondered about that. I presume the assumption is that it is the last ones that are missing. When I thought about it, I tried to think of a way of indicating invalid bit combinations, so one could have, say, the first 3 and last 3 of the 8 groups of 3 bits allowed but the two middle ones invalid. I gave up on that and decided to say you have to give them all, but I'm happy to go along with it being the last ones presumed missing.
When I think about program rather than person understanding IRP, I think primarily about an IR transmitter. There is then a close association between the meaning of ()* or ()+ and the button or other control used to send the signal. If you were generating a signal to send barely ahead of real time and you had a button (or button-like press/release messages from another system) and you hit the do it again or not choice in ()+, you would make that choice based on whether the button has been released yet.
Your first/middle/last system complicates that a little, but can be fit in (if last is unique then repeat one more time as part of deciding to stop).
Maybe I misunderstood but some semantics you wrote seemed to be demanding more of a top down approach to "repeat or not" rather than on the fly.
I didn't intend more of a top-down approach, I intended it as you have described it. I thought at the time that the wording wasn't entirely clear on that, but it was the best I could do at the time. I don't think my difficulty in finding the right wording indicates any problem with my proposals, such as that they actually do demand more of a top-down approach. I'll see if I can describe this part better.
A question for you, John. Should there be a restriction that only one indefinite repeat is allowed? I can't see that two IRstreams both with + markers would have any use, but I think the behaviour is unambiguous. The first would repeat until the button is released, the second would occur exactly once (or whatever the minimum repeat number was). So it's pointless to do it, but making it invalid just adds one more thing for the parser to check.
__________________
Graham
