Nice! thank
bump
Bumparooni
I really like the addition of the Match block into HS, especially since it supports regex, but new users donāt need to have any idea what regex is to use the Match block. Great job.
I even think I follow the logic of implementing the match with the /i case insensitive flag, so new users wouldnāt potentially get confused by a case sensitive match. That said, the case insensitive match does unfortunately limit what the HS community can do with the Match block.
Would you consider adding a 2nd Match block titled for ācase sensitiveā? This way the users could choose.
Or as a completely transparent alternative for advanced users, you could even work around the JS implementation of applying the case insensitivity flag to entire expression by adding some additional logic to make the HS implementation work like other languages where the case insensitive flag can be turned off by the regex.
For example, first test the userās regex string to see if it begins with (?-i) and if so perform the match without adding the case insensitive flag (after of course stripping out those initial characters from the regex).
Use Cases
- Testing the first word of a sentence for capitalization
- Testing proper nouns for capitalization
- A chess app built to use the standard chess notation FEN which uses both upper & lower case to describe a board setup. (which is what I was wanting to do)
- and Iām sure many, many more
Having two blocks seems confusing, as does custom syntax.
What about a toUpperCase and toLowerCase block instead, or maybe use a regular expression only when in /regex/gi form?
Or maybe a hidden parameter that allows you to change the flags?
match (exp) flags (gi)
Interesting thoughts
Could definitely be useful, but I donāt think changing the case would accomplish the same intent as a case sensitive regex match. If Iām missing it, could you give an example?
I think that might be confusing, no? If I follow the suggestion, then when someone tries to use regex of [0-9] it wouldnāt work?
How would the hidden parameter be accessed? I like this idea since THT needs to ākeep it simpleā and hide the flags (for good reason, since most users wonāt understand regex or why the flags parameter would be there). Also it would give even more flexibility for advanced users to set flags as desired.
Although if one would need to alter the projectās JSON (as easy as that may be), I think very few would actually have the knowledge (or use of your tool) to do that.
The ācustom syntaxā I proposed is a variant of this hidden parameter idea. Just to go back to that, itās not really custom in that itās standard syntax in other languages. If you go here to test it, regex of (?-i)A disables the flag i (when set in the upper right of the GUI) and does not find a match in the string āaā.
Good comments Awesome_E, thank you!
Well you could just lowercase it, but youāre right. Itās not a complete solution, especially if you start to factor in replace and other expression-related blocks
Honestly I donāt like that approach myself either, but itās worth getting your thoughts
Oh interesting
@leaders Could I impose and request a technical correction two posts up to the quoted statement. I also made the grammatical mistake of not saying āIf you goā¦ā, but at least that doesnāt make the statement wrong.
It needs to say (?-i) not (?-1). Not being able to go back and make corrections on this forum is a bummer (and makes it difficult to communicate technically accurate information).
Yes there isn't an explanation of regex in the app at this stage, but I think the feature of regex matches is more intended as an advanced bonus, to start with.
(Advanced users can try using regular expressions for more complicated matches)
I do think these descriptions are too hidden ā you have to press and hold on the block in the keyboard, to see these.
At a base level, the idea of the Match block is that you can subscribe to just sections of messages that objects are publishing. It is powerful enough at the level of just subscribing to words within a message, without getting into patterns yet.
E.g. for example, if I have objects broadcasting messages about their interactions like āknife chop strawberryā, āknife chop orangeā, etc., and later on I wanted to add a sound effect every time the knife chopped something, I can easily add a sound system object that does this:
When message matches "chop"
Play sound ( š )
I donāt have to go into the code of the knife, and add a sound block each time it chops something ā I can just have another object subscribe to the existing messaging system that is broadcasted around the knifeās chopping interactions.
This can be done for lots of other contexts as well ā e.g. if you want to add an object that clones itself for a particle effects explosion after another object is destroyed, it can just subscribe to the ādestroyedā part of existing messages. (Though we donāt have local variables in Hopscotch yet, so this wouldnāt be able to be implemented with a lot of versatility yet ā because you would probably want to be able to use custom arguments for the X and Y positions, of where you want the explosion to happen.)
There are probably better ways to design the languages than what I have put here and used previously in my projects (that is why I wanted to canvas othersā ideas on Designing messaging systems for objects to communicate) but they were just some examples.
And then with regex, you could set up more complex matches. So yes the app is lacking an explanation of regex at the moment, but I think the primary idea with the Matches block is about helping you to try and design your systems to scale more quickly and easily, through messaging (though I do want to have more resources on that idea too) and you can do some interesting things before even getting to regex.
How to distinguish upper and lowercase letters with a Match block
Since the HS Match block implementation forces a case insensitive match, a workaround is required if you need to distinguish between upper and lowercase letters.
Hereās what Iāve done & whyā¦
Step 1: Find an alternate Unicode block of characters in the Basic Multilingual Plane that contains characters A-Z
The letters you see in as youāre reading this are part of the Basic Latin block on the Basic Multilingual Plane. There are many other Unicode āastralā Planes, some of which have characters that look like different fonts of A-Z. But those astral planes require 2 code points to encode the characters (which just means the character will read as a length of 2), which will throw off the length of the whole string and the index of characters in the string.
Emojis, as an example, are on one of these astral planes, which is why HS says this:
But weāre in luck. The Halfwidth and Fullwidth Forms also contains the characters A-Z and is on the Basic Multilingual Plane (will read as length of 1).
Step 2: Replace the Basic Latin uppercase letters in your string with their Fullwidth Unicode equivalents
2.1 Iterate through each character of your string
2.2 Test each character (using the = operator) for an uppercase letter
2.3 Replace uppercase letters with the Fullwidth Unicode equivalent
For x = 0 to len(string)-1
If Char_in(string)_at_index(x) = A then
Set string = Chars_in(string)_at_between(0)_and_(x) + ļ¼” + Chars_in(string)_at_between(x+1)_and_(len(string))
Else If Char_in(string)_at_index(x) = B then
Set string = Chars_in(string)_at_between(0)_and_(x) + ļ¼¢ + Chars_in(string)_at_between(x+1)_and_(len(string))
{continue for all letters}
End If
Next X
Note that the A and the B in the long Set string lines look a little different. These are the Fullwidth Unicode characters
Step 3: Now when you use the modified string with the match block you can distinguish between the upper and lower case character sets. But remember for uppercase to use the Fullwidth Unicode letters in the match string!
Keep in mind that this workaround is intended for use with the Match block. If you Set Text (modified string), it will look funny as the Fullwidth characters change the spacing.
Was this easy? No. Is it prone to errors. Yes. Hopefully a future HS update will include a provision to not use a case sensitive match when desired.
Why did I need to do this?
Well, I wanted to make a chess app where the user could input (or a user variable could record) chess Forsyth Edwards Notation which looks like this
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
and essentially describes the state of game. But this requires uppercase letters for white & lowercase letters for black. Then I wrote this complicated regex to test the formatting of the user inputted FEN
^([1-8prnbqkPRNBQK]{1,8}\/){7}[1-8prnbqkPRNBQK]{1,8}\s[wb]\s(-|(?!.*?([kqKQ]).*?\3)[kqKQ]{1,4})(\s(-|[a-h][36]))?(\s\d+){2}$
Describing what that does in detail would be a whole other post, but just note that the uppercase letters are spaced out. Thatās because theyāre the Fullwidth Unicode characters.
I realize this is TL;DR for most but maybe itāll help out someone else one day 
Happy coding

