I agree with the calculator idea! Mostly because I am a lazy person and don't want to do all that code!

No support, how would you put variables into the block?

Support, this really could help clean up messy equations.

XayCraft360 wrote:

No support, how would you put variables into the block?

(join (x) [+56])

badatprogrammingibe wrote:

Garamol56 wrote:

So this:

Is simpler than this?

(calculate () :: operators)

And anyway that's going to be very hard to create for new scratchers

I never said it's simpler than that, but it is very simple.
I find your second comment very insulting to new scratchers like myself.
Any person that is semi-decent at programming would be able to create this.

That is untrue. When I was a new-scratcher I couldn't create a walking man animation. Your code is way more complex than the code to make a walking man animation. As for the new block idea I give my full support. I think you need to read the community guidelines so you actually know that comments like yours are rude. I hope you understand that I am being truthful and I don't mean to insult you/make you upset by this comment. It is just the truth.

|U| :: #c300ff // My siggy protector

< ''  .. '' :: sensing> :: motion // This is my pet blue block who is very cute!

#purple is perfect! ::sound

Any kind of text-based stuff is rejected. Also this was rejected.

                      BE MOIST B) AND CHECK OUT
 _____              ______ _                          _                 
|_   _|             |  _  (_)                        (_)                
  | |_      _____   | | | |_ _ __ ___   ___ _ __  ___ _  ___  _ __  ___       #RoadToMoist100
  | \ \ /\ / / _ \  | | | | | '_ ` _ \ / _ \ '_ \/ __| |/ _ \| '_ \/ __|
  | |\ V  V / (_) | | |/ /| | | | | | |  __/ | | \__ \ | (_) | | | \__ \
  \_/ \_/\_/ \___/  |___/ |_|_| |_| |_|\___|_| |_|___/_|\___/|_| |_|___/

try https://snap.berkeley.edu/snap/snap.html

You can join in too

TopicBumper wrote:

You can join in too

What?

Anyways I support this, the workaround shown is honestly way too complicated and just having a single block would be way easier.

HTML-Fan wrote:

Any kind of text-based stuff is rejected. Also this was rejected.

That meant text-based coding is rejected, not text-based blocks, which I don't know if you could call it that.

No support: This block will actually make your scripts longer. Compare the following:

(calculate (join (join(join (x)[*])(x)) [+2]) ::operators) // We need the 'join' blocks to plug the variables in
(((x)*(x))+(2))

Maybe a more concise version would help?

(calculate (x)[*](x)[+2]◂▸ ::operators)

Unfortunately, it's still quite a bit bulkier than the original.

Greg8128 wrote:

No support: This block will actually make your scripts longer.

Yeah, that's what I was thinking. This would just swap out endlessly math blocks with endless join blocks, just this time with the threat of confusing syntax added. Would be good to teach children the pain of a missing parenthesis though

That being said, I think that there could be some potential if you need to use text syntax for some reason. This would be nice as an additional block somewhere near the bottom of the operators category, not a replacement of the existing math blocks. Here's a really basic example of what I mean:

ask [Type a math problem] and wait
say (join [The answer is:] (calculate(answer) :: operators))

Bump. Support. This wastes space in complex projects and so would be very usefull.

Greg8128 wrote:

No support: This block will actually make your scripts longer. Compare the following:

(calculate (join (join(join (x)[*])(x)) [+2]) ::operators) // We need the 'join' blocks to plug the variables in
(((x)*(x))+(2))

Maybe a more concise version would help?

(calculate (x)[*](x)[+2]◂▸ ::operators)

Unfortunately, it's still quite a bit bulkier than the original.

It works better the less variables are used, but custom reporters would be better.

Yeah, this seems very text-based, and the workaround isn't that bad with chunky blocks as it still works. I think this will be confusing for new users is well.

Semi-Support. This would be very confusing to new users and its hard to put variables inside this block, but I like it because it gives scratch a more advanced feel in the math category

I think this has a rather niche application (calculator projects), and as both Greg and 2000 thankfully pointed out, you'd still have to add a bunch of join blocks. Also what happens if you do

calculate [1/0 * blablabla ^ syntax error lalalla] :: operators reporter

(Admittedly, I think it would be nice if this was a way to support exponentiation, but we might as well implement that as a block lol)

Or, we could do it the Snap! way:

calculate [x * y] with inputs (x) (y) @delInput@addInput as (30) (24) :: operators reporter //or something similar, I'm no block designerd

But I think that kind of block syntax is best reserved for Snap!.

In summary, while it would be cool to essentially have a mathematical eval() block, I think the way it might have to be implemented just isn't worth it considering the alternative (normal math blocks) and its slightly niche applications.

Edit: not to mention, there might be confusion over exactly how to use it. Kids might be used to the () * () block, but they still might try to use an x symbol for multiplication and a ÷ symbol for division, which could be a tad confusing.