LabVIEW
Is CLAD or even CLD possibly in just two months?
wiebe@CARYA wrote:
@alexderjuengere wrote:
I believe to remember, I learned from CLAD, that the selector of a case structures accepts ranges e.g. "0","1..10","11"...This is very tricky though.
1..5 matches [1, 5], so 1, 2, 3, 4, 5
"1".."5" matches ["1", "5"), so "1", "2", "3", "4"
Well, "1".."5" doesn't just match "1", "2", "3", "4".
It also matches "1...", "2...",, "3...", "4..." with ... being ANY 0 or more characters.
And yes this example might be misleading, making people believe that it has anything to do with the number, but it is simply using the actual ASCII code, so "a".."z" will match any string that starts with a lower case letter too, except strings starting with z. If you want to include strings starting with z in the range too, you would have to write "a".."{". Not exactly intuitive, but the alternative would have been simply ill-defined.
Since string ranges are not an exact match anymore but simply indicate the starting character sequence, the last element in the range is non-inclusive. Otherwise you couldn't specify a range for any string starting with "a" without including also "b". So you can be sure that there has been quite a bit of discussion, deliberation and fighting going on when this feature was defined!
Back when the case structure was added to LabVIEW (we are talking LabVIEW ~2 here) regex was something only talked about by “real” programmers. It originates from the Unix world and Pearl’s implementation eventually got the de facto standard that most people mean today when talking about regex.
LabVIEW also had a Search Pattern function that I still prefer in most cases to the Regular Expression since its syntax is simpler and doesn’t put my brain synapses into contortion when trying to figure out the search pattern. But back then the string range selector in the case structure was a valuable feature for not to involved selection ranges.
The main reason it did not gain to much adaption in the end is likely because it is fairly limited and the Search Pattern node was in most cases just as easy and more powerful. The somewhat unintuitive notion of the non-inclusive upper range limit did not help either.
A side effect is the fact that for string searches, the following is allowed (not broken) because the ranges don't actually overlap.
OTOH, the following is broken because the cases are not unique (i.e. the "11" is part of the first range)
