Use labels instead of numbers in i18n

[kristiank]

I changed so that we now can refer to inputFields as textual labels in the translation strings instead of positional numbers. In the last commit you can see some translations changed as well.

[kristiank]

I took the liberty not to use the variable names defined in the Blockly blocks, but they do work as a kind of sanity test :-)

[kristiank]

I noticed the interface doesn't show the blocks for evaluating functions with arguments and executing procedures with arguments, is there a technical reason for this?

Also I have a question about the return block. It is currently displayed only below the Procedures pane, but wouldn't it make sense also showing it under the Functions pane? I understand this is somewhat complicated decision, as procedures are a subcase of functions, so there has been taken the decision to have separate blocks for procedures and functions ... But I simply wanted to draw attention to it, in case you maybe just had forgotten it.

[kristiank]

I think this could be merged, it also fixes issue #13.

[RichoM]

I noticed the interface doesn't show the blocks for evaluating functions with arguments and executing procedures with arguments, is there a technical reason for this?

I made those blocks appear only after you added a procedure/function with the same number of arguments. The idea is to avoid syntax errors. I did the same thing for some of the variables blocks, they don't show up unless a variable is declared. And also for the sonar, joystick, and DC motors: the panel will appear empty until you click the "Configure ..." button. Do you think this is confusing? Maybe I can show the blocks but disabled somehow?

Also I have a question about the return block. It is currently displayed only below the Procedures pane, but wouldn't it make sense also showing it under the Functions pane? I understand this is somewhat complicated decision, as procedures are a subcase of functions, so there has been taken the decision to have separate blocks for procedures and functions ... But I simply wanted to draw attention to it, in case you maybe just had forgotten it.

It would also make sense to show it in the Tasks pane, actually. You can use the return statement pretty much anywhere. The same is true for the return_value block. Maybe we can improve the compiler to forbid using these statements where they don't make sense. You are right that I want to emphasize the idea that procedures and functions are different things. I don't know if that is a good idea, though.

[kristiank]

I made those blocks appear only after you added a procedure/function with the same number of arguments. [snip] Do you think this is confusing? Maybe I can show the blocks but disabled somehow?

I will need to check that with real user's reactions, as I myself was looking at it more from a debugging point of view (I wanted to see whether the blocks were functioning). I think it is okay to have them hidden, although disabled would also be an option. Let's leave it like it is for now.

But I have a question about the function and procedure call blocks. If the name of a procedure is changed, then the corresponding call-block's name changes also. This is very nice. But the names of arguments don't seem to be linked the same way. Because the names are not linked, it is a bit confusing and I was thinking of removing them. How hard do you estimate it to be to link them together? I could do the corresponding changes so that the argument names also is part of the translation strings of the call-blocks. I'll try to read the code myself also.

Maybe we can improve the compiler to forbid using these statements where they don't make sense.

What would your approach to this be? I have been thinking on the blocks' types as a way to prevent illegal combinations. Block types could also be reflected with the block colors. I have noticed the Boolean type blocks under Mathematics are correctly typed, but the color suggests they still are of type Number. Another mismatch seems to be with Pins, they seem to be Numbers which kind of makes sense for experienced users, but for someone new to the game it might be hard to understand what is the difference between number 1 and D1 and A1.

You are right that I want to emphasize the idea that procedures and functions are different things. I don't know if that is a good idea, though.

I don't mind it. If for someone who wants to create a block that makes a certain servo or stepper motor motion sequence the teacher tells to use a procedure, I think it is fine. Although I admit some days I don't like that things are called differently but differs only slightly. But this all depends on the viewpoint and I think it is good that we have many blocks instead of just three for complete lambda calculus :-).

[RichoM]

Sorry for the late response, I took a few days off from work.

How hard do you estimate it to be to link them together? I could do the corresponding changes so that the argument names also is part of the translation strings of the call-blocks. I'll try to read the code myself also.

I don't remember why I didn't do it when I linked the procedure/function names. I vaguely remember some issue with the Blockly version that was fixed in a later version but I can't tell exactly what the problem was. Anyway, I think it could be relatively easy to fix, although it might be a little boring. You should probably start by changing the block definitions to use a Blockly.FieldLabel instead of a hardcoded string for each arg label in the calling blocks. This would allow you to reference the labels by name and update their value whenever the corresponding argument is renamed. Then you should do something like this: https://github.com/GIRA/UziScript/blob/ed5ac2415d79dc7000452e489f7f326357883e50/web/ide/blocks.js#L2163-L2182

This function runs whenever the blockly workspace is updated. If the event corresponds to the renaming of a procedure, it will walk over the blocks looking for the fields that need to be renamed and it will update their value to the new name. I think you should probably write a function like this for the argument names. I don't think anything else is needed but I might be forgetting something.

[RichoM]

What would your approach to this be?

In the smalltalk code there is a class called UziParseTreeValidator that validates that each node in the tree is valid. For instance, for the "variable node" it checks that the variable is defined in the scope. If an invalid node is found it throws a syntax error. I could specify that return nodes are only allowed inside procedures and return-with-value is only allowed inside functions. Of course, this will be an incomplete solution because we should also change the UI to forbid this invalid programs in the first place. I don't know how to do that using blockly yet, though, but I assume it won't be very hard.

I have been thinking on the blocks' types as a way to prevent illegal combinations. Block types could also be reflected with the block colors. I have noticed the Boolean type blocks under Mathematics are correctly typed, but the color suggests they still are of type Number. Another mismatch seems to be with Pins, they seem to be Numbers which kind of makes sense for experienced users, but for someone new to the game it might be hard to understand what is the difference between number 1 and D1 and A1.

Yes, PLEASE review the block colors and fix them as you see fit. Thanks!