Wild Cards for Case Labels

[Jannis]

Ever came across this BD-space killing case arrangement when trying to write a text parser for your external hardware?

I have this idea about a wild card (*) . Freeing up code-space quite a bit!

Of course also possible with a comma string list.

The inside case border of the wild carded case will have the before/match/after substring connectors of the MatchPattern.Vi

[MichaelBalzer]

It's an interesting idea, kind of like the "1.." notation for numeric inputs. What would happen if I have two cases, "Moto" * and "Motor" * with the input Motor1? Which case gets the match, or would this be flagged as an error at edit time by LabVIEW?

I'd probably opt for a well crafted regex on the input (and chuck it in an inlined subVI to save space). You should check out regular expression if you haven't used them before - they may help address the initial problem you encountered.

[AristosQueue (NI)]

Jannis:

Let me start by saying that what you have pictured there is notoriously hard-to-maintain code. If you were on my dev team and tried to submit that VI, I'd send you back to rewrite it as a subVI that translates a string to an enum of commands and then the enum is wired to the case structure. I *might* let you get away with something like what MichaelBalzer posted, where you pull the fixed prefix off and have a single "if" case on that, because the data payload is fixed. On the other hand, I *might* require you to create a Command class and a bunch of child classes, one per command, and translate the string into an object for that command. It would depend upon the complexity of the parsing and the number of data types being mixed together. But there's no condition under which the cascade of regex statements would fly. Its simply too fragile as a parser to be sure that an earlier case hasn't excluded a later case or that fixing a bug up front hasn't injected one downstream (not to mention the performance downside of multiple times scanning the string). You are bordering on needing a true token parser for this kind of work. (Ever wondered what the "Scan String For Tokens" primitive is for? If those commands of yours start having data, you've crossed the line to needing it.)

Given that it is not code I would encourage any developer to write, I am loathe to say we should add features to make it easier to write that code. So even if it could be done, I have doubts that we should do it. 🙂

But... can we even do it?

The case structure must prove mutual orthogonality (i.e., the VI has to break if two cases can both claim the same string), and if I recall my CS courses, that's impossible to prove for an arbitrary regex system -- as in mathematically proved to be impossible to prove. (In fact, that impossibility is exactly what makes the code so fragile.)

Suffixes and prefixes... those are potentially possible. I think it is possible for the compiler to prove, for example, that no case structure can have both "A*" and "*B" (because the string "AB" would match both).

The major downside that I see then is that it is neither regex nor is it a simple string match. It's some other notation that we've invented. Minilanguages (which is what the case structure ring is) need to be minimal in their syntax or they become entire embedded languages. Even worse in LabVIEW: they aren't graphical.

From a UX perspective, I see some downside. we don't normally require users to type the quote marks. To use this feature, users would have to formally type the quote marks because

"A"*

and

"A*"

would have very different meanings. I don't know what LV should/would/could do if the user just typed

A*

Which one, if any, should LV interpret that as?

Speaking as a LV User, there are enough oddities about this that I would, personally, oppose adding this syntax to LabVIEW.

Speaking as a member of LV R&D, I would be loathe to add this feature and would argue that it needed a fair number of limitations and safeguards before going in.

You're right that it saves code right at the moment. I'm suspicious that in the aggregate across users, any time savings there would be eaten by time lost to debugging.

[Jannis]

Boy, it feels good, to get your head washed by AQ :-{

And yes, even after 11years of LV there are still a few primitives I'm wondering what they are for! (is it me or is it the function's description?).

So I agree that the "Scan String For Tokens Function" thrown in a subVI will lighten up my BD - and naturally my commands have data attached.

Of course my first real-LV example is notoriously hard-to-maintain code.That's why I was looking for a more clearer way!

Now I've got my wild cards at the function's "operators"-array instead of where everyone could see them (the case selector), but hey, a small price to pay for avoiding AQ's CS-dilemmas. (Sounds to me like there were some of those in the Tokens function: Note:  If the strings + or – are defined as operators, the function does not recognize leading, or unary, + and – signs. The function always returns them as separate tokens. This is an exception to the "longest match" rule.  .....

Bottom line: I'm happy with this set-up and if you feel like that, close the idea as "already implemented".

How do you enter the Kudos for idea comments? One to MichaelBlazer and one to AQ.

Thanks

[AristosQueue (NI)]

> Boy, it feels good, to get your head washed by AQ :-{

Sorry about that -- I was a bit harsh on that post. But I'm glad the feedback was helpful.

[drjdpowell]

Just a note in case anyone was not aware, but we do have limited “wildcard” ability now, by using ranges.  So “Motor”..”Motos” will match anything starting with “Motor” (though I usually use “Motor”..”Motor~~~”).  You could also use “Motor0”..”Motor9999” to be more specific to numbered motors.

[crossrulz]

I would use "Motor0".."Motor:" for the numbered items.  Remember that the stop of the string range is NOT inclusive.

[drjdpowell]

There is a readability problem here (for those who don’t dream in ASCII and know that “:” is one higher than “9”).  So I always use “~~~” to mark a text range (I never use anything more complex than “Starts with...”).  Tilda is ASCII 127, above all letters, numbers, and likely-used characters.  Using three tildes is just to make it more conspicuous.

[Jannis]

Ohhhhh! There are even more things hidden in LV I wasn't aware of. Guess you have to be a Dr. or a Knight to find out.

Well great! The string range is certainly getting a job done quickly. And even the CS-dilema has been taken care of: A case with "Motor".."Motos" and another on with "Moto".."Motp" will break the Vi. (Wonder how they did that, AQ?)

Still searching for the Kudos button at the IdeaExchange! Thanks drjdpowell and crossrulz.

Now definitely "Idea already implemented"

[Darren]

Original poster requested that the idea be closed as 'Already Implemented'.