You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

cookieclickerer33 wrote:

You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

exact

cookieclickerer33 wrote:

(#181)
You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

Now give me that list without breaking Scratch, then realize you can't and then simstaniuosly find the ACTUAL refutation,

-Cubism007- wrote:

cookieclickerer33 wrote:

You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

exact

?

In JavaScript there’s a unicode() function that gets the Unicode of a character without having to do that already, so this is not that hard to add

cookieclickerer33 wrote:

-Cubism007- wrote:

cookieclickerer33 wrote:

You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

exact

?

In JavaScript there’s a unicode() function that gets the Unicode of a character without having to do that already, so this is not that hard to add

Yes, but kids will not 100% understand unicode blocks.

-Cubism007- wrote:

cookieclickerer33 wrote:

-Cubism007- wrote:

cookieclickerer33 wrote:

You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

exact

?

In JavaScript there’s a unicode() function that gets the Unicode of a character without having to do that already, so this is not that hard to add

Yes, but kids will not 100% understand unicode blocks.

That’s not a valid argument in the slightest

We have

([asin v] of (9))

That’s only thought in calculus, by then you won’t be a kid anymore

There’s still things that even you don’t fully understand on scratch

Even googling asin it’s gonna be hard to fully understand. But googling Unicode numbers is not gonna take nearly as long to figure out as well.

This is clearly very easy to add as snap has this and was one of the earliest added features.
Unicode wouldn’t even need to be mentioned in the block at all anyway

Maybe don't add this as a main block. Make it an extension. Pen is hard to understand, it's an extension. So why not for the Unicode.

calculus blocks

NexusSfan wrote:

Maybe don't add this as a main block. Make it an extension. Pen is hard to understand, it's an extension. So why not for the Unicode.

calculus blocks

pen wasnt an extenstion till scratch 3, no idea why it was made one as its really not that advanced

There are plenty of inappropriate unicode characters kids 8+ don't need to see. Plus, unicode changes by the day.
Should this only work for the Unicode allowed for Scratch comments (Low codes #s)?

-Expo wrote:

There are plenty of inappropriate unicode characters kids 8+ don't need to see. Plus, unicode changes by the day.
Should this only work for the Unicode allowed for Scratch comments (Low codes #s)?

unicode() is in javascript and does all the work for scratch team themselves

also, okay then??? plenty of characters that are on keybords can be seen as suggestive if you wanna make that argument

joefarebrother wrote:

I suggest 2 new blocks to be added to scratch:

(convert number (65) to symbol :: operators) // returns A
(convert symbol [A] to number :: operators)  // returns 65

Every character that can be stored in a computer has a number associated with it, which is called it's “unicode codepoint”. Whenever it stores a character, it's actually storing this codepoint. (You may have also heard of ASCII, that's a much smaller set of characters which is backwards compatible with unicode, which contains the Latin alphabet, Arabic digits, and some symbols). Unicode includes characters from lots of different languages, as well as mathematical symbols, emojis, and more. Most programing languages have ways to convert between characters and numbers (some only support ASCII, but many support full unicode), but scratch doesn't. Snap!, a scratch mod, does.

If you passed in an invalid codepoint, it could return an empty string, and if you pass in more than one character it could return NaN or -1

Note that this is the unicode codepoint, and not dependent on any particular encoding, i.e. UTF8 or UTF16)

Why would it be useful to convert between numbers and characters? Well, firstly you could do case sensitive =, as the unicode of A is 65, but of a it's 97, so you can do

 
<(convert symbol [A] to number :: operators ) = (convert symbol [a] to number :: operators )> // returns false 

You could check if something is an uppercase letter, lowercase letter, digit, or something else by checking the relevant ranges, without having to have a list for different types if symbols and do contains as that's inefficient

You could implement a simple case converter:

 
set [letter num v] to (convert symbol (letter) to number :: operators )
If <<(letter num) > [64]> and <(letter num) < [91]>>
  set [letter v] to (convert number ((letter num) + (32)) to symbol :: operators ) // to lowercase 

(I say simple because it only deals with ASCII, i.e. English letters)

You could use newlines in text without hacked blocks:

 
Say (join [hello] (join (convert number (10) to symbol ::operators ) [world!])) 

It would also be VERY useful for things like cloud list engines where you need to encode text as numbers. Usually you have to have a string containing all the characters, and search through it when you need to encode a character, and some trick to get it to compare case sensitively, which is inefficient and obviously doesn't support all unicode characters.

There is no workaround (only a partial workaround I just described, which might work for ASCII, but certainly not for unicode)

If you're thinking “But that might be confusing, not everyone would understand it or need it” - same thing is true for the trigonometry blocks. The point of Scratch is to learn programming, and this is a feature most programming languages have.

The ST could change the names to something more understandable if needed.

The couldn’t it would allow cloud chats

cloud chats are already banned

cookieclickerer33 wrote:

cloud chats are already banned

realmasterlevi wrote:

joefarebrother wrote:

I suggest 2 new blocks to be added to scratch:

(convert number (65) to symbol :: operators) // returns A
(convert symbol [A] to number :: operators)  // returns 65

Every character that can be stored in a computer has a number associated with it, which is called it's “unicode codepoint”. Whenever it stores a character, it's actually storing this codepoint. (You may have also heard of ASCII, that's a much smaller set of characters which is backwards compatible with unicode, which contains the Latin alphabet, Arabic digits, and some symbols). Unicode includes characters from lots of different languages, as well as mathematical symbols, emojis, and more. Most programing languages have ways to convert between characters and numbers (some only support ASCII, but many support full unicode), but scratch doesn't. Snap!, a scratch mod, does.

If you passed in an invalid codepoint, it could return an empty string, and if you pass in more than one character it could return NaN or -1

Note that this is the unicode codepoint, and not dependent on any particular encoding, i.e. UTF8 or UTF16)

Why would it be useful to convert between numbers and characters? Well, firstly you could do case sensitive =, as the unicode of A is 65, but of a it's 97, so you can do

 
<(convert symbol [A] to number :: operators ) = (convert symbol [a] to number :: operators )> // returns false 

You could check if something is an uppercase letter, lowercase letter, digit, or something else by checking the relevant ranges, without having to have a list for different types if symbols and do contains as that's inefficient

You could implement a simple case converter:

 
set [letter num v] to (convert symbol (letter) to number :: operators )
If <<(letter num) > [64]> and <(letter num) < [91]>>
  set [letter v] to (convert number ((letter num) + (32)) to symbol :: operators ) // to lowercase 

(I say simple because it only deals with ASCII, i.e. English letters)

You could use newlines in text without hacked blocks:

 
Say (join [hello] (join (convert number (10) to symbol ::operators ) [world!])) 

It would also be VERY useful for things like cloud list engines where you need to encode text as numbers. Usually you have to have a string containing all the characters, and search through it when you need to encode a character, and some trick to get it to compare case sensitively, which is inefficient and obviously doesn't support all unicode characters.

There is no workaround (only a partial workaround I just described, which might work for ASCII, but certainly not for unicode)

If you're thinking “But that might be confusing, not everyone would understand it or need it” - same thing is true for the trigonometry blocks. The point of Scratch is to learn programming, and this is a feature most programming languages have.

The ST could change the names to something more understandable if needed.

The couldn’t it would allow cloud chats

It would make it waaaaaaaaaay easier to make cloud chats

cloud chats are already banned so it doesnt matter

you would still have to encode and decode reguadless because a character could be 3 decimal spaces or 1 decimal space. i dont see a way you could realistically use these to create a cloud chat that way

cookieclickerer33 wrote:

cloud chats are already banned so it doesnt matter

you would still have to encode and decode reguadless because a character could be 3 decimal spaces or 1 decimal space. i dont see a way you could realistically use these to create a cloud chat that way

It would be super easy to make cloud chats. Its the same reason cloud lists are rejected

A_Nyan_In_Space wrote:

cookieclickerer33 wrote:

cloud chats are already banned so it doesnt matter

you would still have to encode and decode reguadless because a character could be 3 decimal spaces or 1 decimal space. i dont see a way you could realistically use these to create a cloud chat that way

It would be super easy to make cloud chats. Its the same reason cloud lists are rejected

cloud lists are rejected because of server costs and that

this again i dont see a way to actually make this into a cloud chat as they arent a consistant length

cookieclickerer33 wrote:

-Expo wrote:

There are plenty of inappropriate unicode characters kids 8+ don't need to see. Plus, unicode changes by the day.
Should this only work for the Unicode allowed for Scratch comments (Low codes #s)?

unicode() is in javascript and does all the work for scratch team themselves

also, okay then??? plenty of characters that are on keybords can be seen as suggestive if you wanna make that argument

what about ‘EGYPTIAN HIEROGLYPH D053’ (U+130BA)?

Mockups:

(character (32) ::operators)
(unicode of ( ) ::operators)

cookieclickerer33 wrote:

You say it wouldn’t make anything easier and then proceed to state you like what it adds??

The alternative to this is using a list of every Unicode character and getting that with an index

That's what I actually covered about the thousands of exceptional cases in my previous post (#163) about the case-insensitivity of (item #) block.

An additional note: many adjacent unassigned characters equal one another in Scratch. This means the typical 2-sprite method is far less than enough for general case-sensing as thousands of characters are all equal.

Also, if one even consider code point instead of char code for stuffs that shows up as a single character (including emojis), then the list has to be 0x110000 (1114112) instead of 0x10000 (65536) in size.

For cloud chat statements, just like all other possible methods of encoding texts, unicode is just a wider subset of characters. This does not add to the possibility that encoding characters within a subset of unicode is already possible. Anything that raises moderation concern no matter what mechanism is used (including those not text-based, such as a cloud-based canvas) is still not allowed in Scratch. Therefore, it is off-topic to relate unicode support to cloud chat.

support… though wouldn't it be easier to not make a separate block and just make it an option of the “___ of” block?

([unicode v] of (put this here))::green

idk.. maybe someone has put this out there in the 10 pages this suggestion has.