Expression variables not case-sensitive

Hey Fellows,
To be honest I did not know where this Topic really belongs, but it’s clearly GH related. Feel free to move/delete or enlighten me otherwise :wink:

While dealing with a quite long mathematical formula in the expression editor in grasshopper, I encountered a problem. While it is a really simple one, it took me ages to figure out, so now I am sharing for others. And I like to ask a question to the devs aswell:

Grasshopper Expression-Variables are not case sensitive!
Okay okay, I know that the capital B is completely useless in this expression. Once taken out, the expression evaluates fine. I originally encountered the problem in a much larger expression involving these two variables. And I used b and B to reflect the real physical formula.

Now that I have explained, I’d like to ask the question: Is this intended or is it a bug?
While this may not be the case for everybody, the thought of non-case-sensitive expression-variables makes my brain hurt. Eventhough I know it now, I would strongly argue for case-sensitivity of these variables/parameters.

@DavidRutten
As always, I am hoping for your thoughts/opinions/explanations :slight_smile:

RH Build: Version 6 SR8 (6.8.18240.20051, 08/28/2018)
GH Build: 1.0.0007, Tuesday, 28th August 2018

Max

This is true and by design. The expression language is modeled (loosely) on VBScript, which is not case-sensitive.

The new language in GH2 is a variant of C# and as such does care about casing. We’ll have to see whether that causes confusion.

3 Likes

Since expression syntax resembles the syntax inside python why not directly use python. It will save you the coding actually developing an expression language with csharp. Also if it is python it will be “lighter” on the processor. Unless you already developed that rendering my suggestion moot. :slight_smile:

Can I make python understand the operators and constants that are part of the GH1 language? Such as superscript powers, factorials, sigma summation etc? Can python handle replacement of undeclared variables with method groups?

Even if it could (I honestly don’t know, which is another reason for me not to mess with it), it requires the DLR to run which would complicate the core project, which is CLR only.

The benefit of C# is that it can be tokenised, parsed, symbolised and compiled using the very powerful Roslyn api written and maintained by Microsoft. I trust its correctness as it is used by VS and the framework itself, and I trust its future-proofing.

3 Likes

As always, thank you for the great insight and explanation, David!
I didn’t even know that VBScript is not case-sensitive, there’s always something one can learn!

While it’ll certainly be a longer wait, even this small feature makes me excited for GH2 :wink: