6d66yh wrote:

rdococ wrote:

Everyone suggesting C operators wrote:

<snip>

That's the point. Changing the Scratch's abstractive numerical type is off-topic to this and should not be discussed here. Adding native integers separately like they are done in C, C++, etc. is what this suggestion is all about. Even the ‘double’ type among the ones suggested will still be different from var because it preserves the IEEE standard interpretation of NaN and makes it possible to make arrays of it by casting malloc's output and possible to cast its pointer to a 64-bit integer pointer to natively read its bits.

In that case, no support. There's no reason to include all of these different kinds of number into Scratch just because you watched a couple C tutorials. Not everyone using Scratch will understand it, and many won't even go on to use C as adults. All this suggestion would do is confuse.

Edit: Not to mention that this might not even be possible to do anyway. Scratch runs in Javascript now, and Javascript only has a single numerical type, which are 64-bit floats.

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

fdreerf wrote:

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

Virtually no Scratch project is native because of lack of integers and their pointers (as well as local integers and heap integers and their memory allocation and deallocation).

6d66yh wrote:

fdreerf wrote:

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

Virtually no Scratch project is native because of lack of integers and their pointers (as well as local integers and heap integers and their memory allocation and deallocation).

And?

6d66yh wrote:

fdreerf wrote:

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

Virtually no Scratch project is native because of lack of integers and their pointers (as well as local integers and heap integers and their memory allocation and deallocation).

The native number type for JavaScript, which Scratch is written in, is a 64 bit double, not a 64 bit integer. An implementation of 64 bit integers in Scratch would likely require emulation which would be much slower and difficult to develop for relatively little gain.

If you really believe that integers and pointers are necessary for the implementation of any algorithm, you have been learning to program wrong. Programmers should be able to think outside the box and work around restrictions in creative ways. You are thinking inside the box of a different programming language rather than starting inside Scratch's box and reaching out to see what is possible.

imfh wrote:

6d66yh wrote:

fdreerf wrote:

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

Virtually no Scratch project is native because of lack of integers and their pointers (as well as local integers and heap integers and their memory allocation and deallocation).

The native number type for JavaScript, which Scratch is written in, is a 64 bit double, not a 64 bit integer. An implementation of 64 bit integers in Scratch would likely require emulation which would be much slower and difficult to develop for relatively little gain.

Integer arithmetic would be much faster because Scratch developers would put inline assembly code in Java-script to natively use integers.

imfh wrote:

If you really believe that integers and pointers are necessary for the implementation of any algorithm, you have been learning to program wrong. Programmers should be able to think outside the box and work around restrictions in creative ways. You are thinking inside the box of a different programming language rather than starting inside Scratch's box and reaching out to see what is possible.

But there's no way to workaround nativity. It doesn't end up any more native regardless of workarounds. Integer arithmetic will make the code more native. The definitive set of integer arithmetic blocks is linked in my signature.

6d66yh wrote:

fdreerf wrote:

6d66yh wrote:

Bump. Integers and their pointers are extremely necessary for any implementation of any algorithm of any sort.

Well, clearly not “extremely necessary” for every project on Scratch ever created up to and past this point.

Virtually no Scratch project is native because of lack of integers and their pointers (as well as local integers and heap integers and their memory allocation and deallocation).

Scratch is an interpreted programming environment. There is no Scratch heap - rather, Scratch stores the current stack frame of any running scripts, and that stack frame is represented as a Javascript object, with fields referring to its inputs, the stack frame below it, and so on. All of the work of managing where this actually gets allocated is left to whatever Javascript implementation your browser is using.

The very language that Scratch is programmed in does not have this fine-grained control over memory allocation that you seem to want, nor is it appropriate for a programming language with heavily simplified concurrency and object models where you build scripts out of cutesy-looking pastel blocks.

6d66yh wrote:

Integer arithmetic would be much faster because Scratch developers would put inline assembly code in Java-script to natively use integers.

It is much more difficult than just adding inline assembly code. The Scratch Team would have to write a library in a language which can be compiled to WebAssembly which allows them to use 64 bit integers, then completely redo the create a new variable system to support different data types(which adds overhead), then redo create new operators to do different things depending on the data type (also adds overhead). If pointers are in the mix, they would also have implement a custom memory allocation system while making sure that it is impossible to create a memory leak or modify memory the project isn't supposed to.

6d66yh wrote:

But there's no way to workaround nativity. It doesn't end up any more native regardless of workarounds. Integer arithmetic will make the code more native. The definitive set of integer arithmetic blocks is linked in my signature.

Native to what? The physical hardware the computer is running on? I don't see how this additional “nativity” provides any advantages to Scratch except a possible slight performance increase for those who manage to take full advantage of the features.

An important question: “Is the effort of adding native 64 bit integer support worth the benefits it will provide the Scratch community?” When asking this, remember that the Scratch Team has limited time for development, so if they can work on something else for the same amount of time with a greater reward, they will most likely do that instead.

imfh wrote:

6d66yh wrote:

Integer arithmetic would be much faster because Scratch developers would put inline assembly code in Java-script to natively use integers.

It is much more difficult than just adding inline assembly code. The Scratch Team would have to write a library in a language which can be compiled to WebAssembly which allows them to use 64 bit integers, then completely redo the variable system to support different data types(which adds overhead), then redo operators to do different things depending on the data type (also adds overhead). If pointers are in the mix, they would also have implement a custom memory allocation system while making sure that it is impossible to create a memory leak or modify memory the project isn't supposed to.

What? Have you even seen the definitive list at https://scratch.mit.edu/discuss/post/5163608/ ? The integers will have nothing to do with the overly abstractive variable system and its operators. There will also be 8-bit integers, 16-bit integers, 32-bit integers, as well as floats, doubles, and long doubles. It also won't add overhead because the Scratch interpreter could internally convert each operation to a strong type operation (making it native as the type has already been handled). And they won't have to implement custom memory allocation, we already have it in gcc so they could port it directly. There won't be checks for memory leaks, as that would be absurd and impossible due to the halting problem. An access violation, etc. will simply make the interpreter use native exception handling, and make the project return an integer.

imfh wrote:

6d66yh wrote:

But there's no way to workaround nativity. It doesn't end up any more native regardless of workarounds. Integer arithmetic will make the code more native. The definitive set of integer arithmetic blocks is linked in my signature.

Native to what? The physical hardware the computer is running on? I don't see how this additional “nativity” provides any advantages to Scratch except a possible slight performance increase for those who manage to take full advantage of the features.

An important question: “Is the effort of adding native 64 bit integer support worth the benefits it will provide the Scratch community?” When asking this, remember that the Scratch Team has limited time for development, so if they can work on something else for the same amount of time with a greater reward, they will most likely do that instead.

I don't think literally native code is merely a slight performance increase. There are all kinds of software much faster than any Scratch project due to nativity. You have probably literally used a real time TrueType renderer during typing your posts. Scratch can't even get reasonable bitmap rendering, which we could get by native integer access to the screen memory.

6d66yh wrote:

What? Have you even seen the definitive list at https://scratch.mit.edu/discuss/post/5163608/ ? The integers will have nothing to do with the overly abstractive variable system and its operators. There will also be 8-bit integers, 16-bit integers, 32-bit integers, as well as floats, doubles, and long doubles. It also won't add overhead because the Scratch interpreter could internally convert each operation to a strong type operation (making it native as the type has already been handled). And they won't have to implement custom memory allocation, we already have it in gcc so they could port it directly. There won't be checks for memory leaks, as that would be absurd and impossible due to the halting problem. An access violation, etc. will simply make the interpreter use native exception handling, and make the project return an integer.

Yes, I read the list, but I missed the local variable block and assumed this would use regular variables. If not memory leaks, access violations would still need to be prevented. If I am correct, native access violations do not prevent an application from modifying its own memory. If someone can modify the webpage's memory, it would be possible to run an arbitrary code execution which could do something like deleting projects, creating a project which when run, remixes and shares itself, making inappropriate comments, etc.

6d66yh wrote:

I don't think literally native code is merely a slight performance increase. There are all kinds of software much faster than any Scratch project due to nativity. You have probably literally used a real time TrueType renderer during typing your posts. Scratch can't even get reasonable bitmap rendering, which we could get by native integer access to the screen memory.

Native access to the screen would be unlikely provide a increase to bitmap rendering performance when running something as simple as an empty loop through 2 million iterations takes 0.4 seconds to complete. That means you can have around 170,000 loop iterations per frame before Scratch starts to run below 30 fps.

The bottleneck in Scratch's performance isn't the lack of native data types; it is the fact that Scratch is an interpreted language (Scratch) running in an interpreted language (JavaScript). Even WebAssembly is interpreted, and I don't know if it can give raw access to the display.

imfh wrote:

6d66yh wrote:

What? Have you even seen the definitive list at https://scratch.mit.edu/discuss/post/5163608/ ? The integers will have nothing to do with the overly abstractive variable system and its operators. There will also be 8-bit integers, 16-bit integers, 32-bit integers, as well as floats, doubles, and long doubles. It also won't add overhead because the Scratch interpreter could internally convert each operation to a strong type operation (making it native as the type has already been handled). And they won't have to implement custom memory allocation, we already have it in gcc so they could port it directly. There won't be checks for memory leaks, as that would be absurd and impossible due to the halting problem. An access violation, etc. will simply make the interpreter use native exception handling, and make the project return an integer.

Yes, I read the list, but I missed the local variable block and assumed this would use regular variables. If not memory leaks, access violations would still need to be prevented. If I am correct, native access violations do not prevent an application from modifying its own memory. If someone can modify the webpage's memory, it would be possible to run an arbitrary code execution which could do something like deleting projects, creating a project which when run, remixes and shares itself, making inappropriate comments, etc.

But arbitrary code execution is the point of a programming language.

imfh wrote:

6d66yh wrote:

I don't think literally native code is merely a slight performance increase. There are all kinds of software much faster than any Scratch project due to nativity. You have probably literally used a real time TrueType renderer during typing your posts. Scratch can't even get reasonable bitmap rendering, which we could get by native integer access to the screen memory.

Native access to the screen would be unlikely provide a increase to bitmap rendering performance when running something as simple as an empty loop through 2 million iterations takes 0.4 seconds to complete. That means you can have around 170,000 loop iterations per frame before Scratch starts to run below 30 fps.

The bottleneck in Scratch's performance isn't the lack of native data types; it is the fact that Scratch is an interpreted language (Scratch) running in an interpreted language (JavaScript). Even WebAssembly is interpreted, and I don't know if it can give raw access to the display.

Native data types would allow there to be an optimizer, like we have in gcc.

6d66yh wrote:

But arbitrary code execution is the point of a programming language.

Arbitrary code execution is only the point within a program's scope. Programs aren't supposed to be able to arbitrarily execute code with root privileges. Anything that runs in a Scratch project must be sandboxed from the rest of the site or it will not be safe.

imfh wrote:

Native data types would allow there to be an optimizer, like we have in gcc.

Native data types alone would not allow an optimizer to be added. Adding an optimizer like gcc would require Scratch to be greatly rewritten, likely with comparable effort to the transition from Scratch 2 to Scratch 3.

OK, your case is more or less that there should be a separate set of blocks for integer arithmetic, because that would be more efficient than either solely floating-point arithmetic or generic arithmetic (i.e. one set of blocks that do both floating-point and integer arithmetic.) The question is, do the gains justify the means of realising them?

The gains in efficiency would be insignificant, like imfh explained, compared to the overhead caused by interpretation. Can I again mention invisible JIT compiler? :P A compiler can compile code with generic arithmetic operators efficiently if it knows when they're used only for numbers of a particular sort, like some Common Lisp compilers do under some circumstances (though I think type declarations are necessary.)

Numbers are an abstract data type so that you can think of computer numbers more like you think of number numbers. (Just like how you don't always have to think of a sampled sound as a sequence of amplitudes at a given frequency.) This is why if you want precision, generic arithmetic is a sensible answer. How the numbers you're working with are represented is not always relevant. If you add two numbers, you add two numbers.

Your rationale for adding pointer blocks isn't clear, because Scratch is garbage collected;

In high-level programming languages like JavaScript, Lisp, ML, and Java, you can just pass around compound data as you please. A datum like an array or object is represented by a pointer, but the programmer doesn't need to know the address is a number or perform arithmetic on it. When it's no longer needed, the garbage collector reclaims the memory. So what you want can be accomplished with first class lists (with a constant factor time and space overhead, unless something like JavaScript's typed arrays were to be added.)

Jonathan50 wrote:

OK, your case is more or less that there should be a separate set of blocks for integer arithmetic, because that would be more efficient than either solely floating-point arithmetic or generic arithmetic (i.e. one set of blocks that do both floating-point and integer arithmetic.) The question is, do the gains justify the means of realising them?

I wouldn't call the abstractive Scratch operators floating point operators. In fact, the definitive list of integer arithmetic blocks includes floating point types. Standard integer and floating point promotion is interpreted on parse time (which may be ahead of runtime). There will be true floating point operations, unlike Scratch's abstractive operators, in particular that NaN are handled correctly, it can be made arrays of and pointed to, and no strings are internally used until a type casting to abstractive var type is done or it is used in an abstractive block.

Jonathan50 wrote:

The gains in efficiency would be insignificant, like imfh explained, compared to the overhead caused by interpretation. Can I again mention invisible JIT compiler? :P A compiler can compile code with generic arithmetic operators efficiently if it knows when they're used only for numbers of a particular sort, like some Common Lisp compilers do under some circumstances (though I think type declarations are necessary.)

And with integer arithmetic, we can have logical code that lets the interpreter know the properties of it. For instance, assignment to zero may be internally replaced with xor-assignment to itself, or multiplication by two may be internally replaced with bitshift left by one, and so on. This internal optimization will not affect the external integer arithmetic block display, but will affect the runtime performance.

Jonathan50 wrote:

Numbers are an abstract data type so that you can think of computer numbers more like you think of number numbers. (Just like how you don't always have to think of a sampled sound as a sequence of amplitudes at a given frequency.) This is why if you want precision, generic arithmetic is a sensible answer. How the numbers you're working with are represented is not always relevant. If you add two numbers, you add two numbers.

Many algorithms rely on specific types to achieve their native performance, with no abstractions necessary. Furthermore, integers and other fixed-size types can be made arrays of and pointed to.

Jonathan50 wrote:

Your rationale for adding pointer blocks isn't clear, because Scratch is garbage collected;

In high-level programming languages like JavaScript, Lisp, ML, and Java, you can just pass around compound data as you please. A datum like an array or object is represented by a pointer, but the programmer doesn't need to know the address is a number or perform arithmetic on it. When it's no longer needed, the garbage collector reclaims the memory. So what you want can be accomplished with first class lists (with a constant factor time and space overhead, unless something like JavaScript's typed arrays were to be added.)

However, pointers are the processor-native way of addressing things. It is necessary for arrays to exist (and integers as well as floating point types and even their pointers themselves are fixed size and so can be made arrays of in the first place). To access an array item, we add the index to the pointer, then dereference the resulting pointer.

6d66yh wrote:

<snip>

Scratch is not designed to be a systems language. It doesn't need strong typing, “native” integers, pointers, manual memory manipulation, or any of the other things you want. Scratch is an educational programming language designed to teach high-level concepts in a simple manner, with its simplified object and concurrency models in the form of sprites and scripts.

You're completely missing the point of what Scratch is meant to be about, and there is zero chance of your ideas being implemented into Scratch. In fact, it's not even possible for most of them without reimplementing the whole thing in a systems language like C, and the Scratch Team has already had to rewrite Scratch twice within the span of a few years. This just isn't what Scratch needs.

rdococ wrote:

6d66yh wrote:

<snip>

Scratch is not designed to be a systems language. It doesn't need strong typing, “native” integers, pointers, manual memory manipulation, or any of the other things you want. Scratch is an educational programming language designed to teach high-level concepts in a simple manner, with its simplified object and concurrency models in the form of sprites and scripts.

You're completely missing the point of what Scratch is meant to be about, and there is zero chance of your ideas being implemented into Scratch. In fact, it's not even possible for most of them without reimplementing the whole thing in a systems language like C, and the Scratch Team has already had to rewrite Scratch twice within the span of a few years. This just isn't what Scratch needs.

Did you have a numerical computation error? Like a NaN turning into zero? It will eventually be implemented.

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

6d66yh wrote:

PkmnQ wrote:

Scratch is not meant for C coders. Scratch is meant for those who want to learn to code. If you want Scratch to be more like C, go to Snap.

Snap is not more like C, as it lacks integer arithmetic, therefore it is off-topic to this suggestion.

Then code it yourself. Advanced stuff like this should be programmed in. Plus, Snap may be easier to implement this in. But they probably will not be natively implemented. Scratch runs on JS, not C. And I think JS doesn't have 64 bit integers.