case sensitive C block (for uppercase, lowercase aware blocks in Scratch)

walkcycle

a C block that makes regular Scratch blocks case sensitive

case sensitive  { 
if <[cat] = [CAT]> then
 false :: grey
else
 does this because cat and CAT are not the same in the case sensitive C block:: grey
  } :: control // control

not sure of the category

case sensing   {

  } :: sensing // sensing

letter case aware  { 

  } :: operators // operators

Last edited by walkcycle (Aug. 29, 2017 19:48:25)

FancyFoxy

I'd love this, actually! Maybe a little different wording:

with case sensitive {} :: sensing

WolfCat67

I'd love this! Would really make it a lot easier for people to make case-sensitive code. After all, the fact that it's not case-sensitive as it is is kind of a let-down in some ways (some ways), so it would really help out with this block.

walkcycle

FancyFoxy wrote:
I'd love this, actually! Maybe a little different wording:
with case sensitive {} :: sensing

yeah, not sure of the wording, either

'with' is an improvement

more trying

sense case   {

  } :: sensing // sensing

turn overlook capital letters off  { 

  } turn overlook captal letters back on:: operators // operators

turn on case sensitive  { 

  } turn off :: control // control

WolfCat67 wrote:
I'd love this! Would really make it a lot easier for people to make case-sensitive code. After all, the fact that it's not case-sensitive as it is is kind of a let-down in some ways (some ways), so it would really help out with this block.

I agree.

Last edited by walkcycle (Aug. 31, 2017 18:30:04)

yzyzyz

I support! this would solve a lot of problems.

-ShadowOfTheFuture-

Support!

smartzx

Duplicate. Seriously, I find 2 pairs of duplicates in the first 10 non-stickied posts I see?

FancyFoxy

smartzx wrote:
Duplicate. Seriously, I find 2 pairs of duplicates in the first 10 non-stickied posts I see?

There's a difference between

<case sensitive [] = [] :: operators>

and

case sensitive {} :: sensing

TheAspiringHacker

Why can't we just have two separate functions? Having a C-shaped block would make the comparison functions impure and the reporter blocks are better designed if they did not depend on external state. Also, how would the block work if it called a custom block that used the comparison functions? Would the custom block be case-sensitive or not? I can see beginners getting confused by the vagueness.

walkcycle

TheAspiringHacker wrote:
Why can't we just have two separate functions?

Scratch has more blocks where case (in)sensitivity comes into play.

For instance,

<[list v] contains [item] ?>

And in Scratch 3.0 (maybe)

<[string] contains [string] ? ::operators >

Also,

<key [ v] pressed?>

could have its list of keys include caps

a
A
b
B

inside the context of the C block.

TheAspiringHacker wrote:
Having a C-shaped block would make the comparison functions impure and the reporter blocks are better designed if they did not depend on external state.

It would make them case sensitive. But yeah, it is not a perfect solution.

TheAspiringHacker wrote:
Also, how would the block work if it called a custom block that used the comparison functions? Would the custom block be case-sensitive or not? I can see beginners getting confused by the vagueness.

I don't think it would extend to change the behavior inside custom blocks used in its context. But it would have consistent, dependable behavior, whatever choice is made.

Charles12310

walkcycle wrote:
TheAspiringHacker wrote:
Why can't we just have two separate functions?

Scratch has more blocks where case (in)sensitivity comes into play.

For instance,
<[list v] contains [item] ?>
And in Scratch 3.0 (maybe)
<[string] contains [string] ? ::operators >
Also,
<key [ v] pressed?>
could have its list of keys include caps

a
A
b
B

inside the context of the C block.

TheAspiringHacker wrote:
Having a C-shaped block would make the comparison functions impure and the reporter blocks are better designed if they did not depend on external state.
It would make them case sensitive. But yeah, it is not a perfect solution.

TheAspiringHacker wrote:
Also, how would the block work if it called a custom block that used the comparison functions? Would the custom block be case-sensitive or not? I can see beginners getting confused by the vagueness.

I don't think it would extend to change the behavior inside custom blocks used in its context. But it would have consistent, dependable behavior, whatever choice is made.

*ahem*

<key [shift v] pressed? :: sensing >

We need this instead.

walkcycle

Charles12310 wrote:
<key [shift v] pressed? :: sensing >
We need this instead.

Then you would have to detect two key presses (instead of one). And Caps Lock is not the same as Shift lock on US keyboards.

TheAspiringHacker

I think that a more elegant solution is if Scratch had lambdas so we can write custom equality functions; the default compare function if none is given would be the case-insensitive equals block.

walkcycle

Scratch 3.0 may have custom reporters, but we would still need a dependable way to get at letter case.

Last edited by walkcycle (Sept. 25, 2017 20:26:44)

TheAspiringHacker

walkcycle wrote:
Scratch 3.0 may have custom reporters, but we would still needs a dependable way to get at letter case.

No, I said lambdas, AKA functions as values. They can be taken as arguments by other functions.

If you want to know what I'm talking about, C++'s hash map can take a equality function that is set to std::equal_to<T> by default. http://www.cplusplus.com/reference/unordered_map/unordered_map/

EDIT: We should have a case-sensitive equality block and a case-sensitive less than block that we can use to define other case-sensitive functions.

Last edited by TheAspiringHacker (Sept. 25, 2017 20:29:57)

walkcycle

I am afraid custom reporters is the best you can hope for in the next Scratch. It would be an improvement. But Scratch still needs a dependable way to get at letter case.

Advanced Topics is over here. Discussion on Snap! currently at top.

+ λ = alonzo

walkcycle

TheAspiringHacker wrote:
EDIT: We should have a case-sensitive equality block and a case-sensitive less than block that we can use to define other case-sensitive functions.

More than one equality block is going to be confusing.

For a case-aware less than (or greater than) block, what should it do with letters?

E.g., is A > a because of size. Or is a > A because of unicode numerical ordering?

How about strings of characters or mixed case?

TheAspiringHacker

walkcycle wrote:
TheAspiringHacker wrote:
EDIT: We should have a case-sensitive equality block and a case-sensitive less than block that we can use to define other case-sensitive functions.
More than one equality block is going to be confusing.

For a case-aware less than (or greater than) block, what should it do with letters?

E.g., is A > a because of size. Or is a > A because of unicode numerical ordering?

How about strings of characters or mixed case?

The case-aware less than block should use the ASCII numbers. The string comparison version should use lexicographical ordering. The less-than block can already compare characters and strings.

Charles12310

walkcycle wrote:
Charles12310 wrote:
<key [shift v] pressed? :: sensing >
We need this instead.
Then you would have to detect two key presses (instead of one). And Caps Lock is not the same as Shift lock on US keyboards.

<caps lock on? :: sensing >

Besides, it will decrease the need to keep scrolling down until you reach the capital letters.

ugli_est

hi (asdf) steps

Discuss Scratch