Right after the words "JavaScript Function," you have three orange blobs; should be plain text strings. It's the formal parameters of the JS function; the Snap! interface comes in the "with inputs" part of the CALL.

my rambling

Oh, I guess it was against my expectations to have the formal parameters (of the JS) in front of, as opposed to behind the function's body because in Snap! I see them mostly behind it. Is there a reason that they're in front in this particular block?

I have to admit I also forgot to put the JS block inside a CALL block, which is kind of embarrassing, but you didn't notice this my omission of the CALL block, either, so I'm not the only one who needs glasses to see better. Hopefully I have learned the "you shouldn't use a JS block without a CALL block" lesson.

Well, unless you put the function in a variable or a list or something, to be used later.

The inputs go in front because that's what JS code looks like!
function(x, y, z) {return 3x+2y-z}

some more rambling

I wonder in which case you would want to put a JS block inside a variable, would it be in order to be able to call it again and again, each time with different parameters? Or something completely different?

Maybe for most users that are familiar with the order in Snap!, the order could still be "a function's body first, parameters follow it", in this block as well?

Yes, exactly. Although the usual thing is to wrap the JS function in a Snap! procedure that calls it.

The idea is that only people who are comfortable writing JS code will use this feature. And while writing JS code, this is the order they expect. The parentheses and braces in the title line of the block are the JS syntax for a procedure definition! So the order really isn't something we can change without losing that connection to JS.

This is how grown-ups think, however, kids were never afraid of doing things they don't know how to do, since this is how kids basically learn anything despite not knowing or, likelier, precisely because of not knowing. I think we, as adults, should encourage kids to try things they don't know yet how to do, and even more, should make this easier to try; that is why I think the JS block, too, should/could have its parameters behind the way other blocks do. The block can show one order to a user, and only internally reverse the order before it passes it to an actual JavaScript to run, I think. It would be a kind of custom block, I guess.

I think you're trying to have it both ways about kids: They're brave enough to experiment with JS Function (and I agree), but will boggle at things being in a different order.

The brave kid you're talking about will look at other people's JS code, in contexts other than Snap!, and so will recognize function (__) {__} as correct JS syntax. That will help them understand that they're expected to put formal parameters in the parentheses, even though what's inside is text slots rather than orange blobs.

Your hypothetical kid is more likely to have read JS code than to have seen a gray ring with formal parameters! Almost always, Snap! programs use implicit parameters (empty slots) in the rings.

Actually, now I think of it, I'm not sure I'm understanding your reasoning. Are you talking about explicit formal parameters in gray rings, or are you talking about actual argument expressions in the CALL and RUN blocks? Because the latter are already in correct JS order for a procedure call: proc(arg1, arg2, ...) and are in any case irrelevant to where to put formal parameters.

You are right. Explicit parameters in Snap! are not being (yet) used as often as implicit ones, so my hypothetical kid argument isn't as convincing as it would be if it was the other way round.

That said, I have corrected the JS block the way you showed me and it does (when tested on its own) work fine, however, when used inside (the MAP block) nothing happens, which is strange and I don't understand it. You can set the JS_block_on Boolean to true to test it in the following project https://snap.berkeley.edu/snapsource/snap.html#present:Username=kinestheticlearning&ProjectName=Media_Map_with_JS_block

The problem (or at least the first one that jumps out at me) has nothing to do with your JS block, but with your use of MAP:

There are seven empty slots in the ringed expression, each of which will be filled with the same item from the PIXELS OF COSTUME block, namely, a pixel, which is a list of four numbers. In the first three slots, which are the list input to an ITEM OF block, you are correctly expecting a pixel, and are using ITEM to extract each of the color coordinates. I think what you're expecting is what you get for the seventh slot also, the ELSE part of the IF. But slots 4 to 6, in the LIST block, seem to be expecting numbers. Because a pixel is a list of four numbers, and LIST is given four inputs, you're hoping that the first three will be filled with the first three numbers of the pixel, rather than with the entire pixel. Instead you need to use ITEM OF in those slots.

Thank you for spending some of your precious time to think what might be the problem. I appreciate it.

It turns out the MAP takes 9 seconds to map all the pixels and it works fine. YAY!!! :- D

(So it works fine the way it is, no need to use ITEMS OF... I just have not been patient enough as using JS variant does not make it much faster, at best 1 second faster, i.e. taking 8 seconds).

Wow, I still don't see how it can work! But, if it does, that's great. :~)

I don't understand why you think it shouldn't work the way it is now. I know you explained it to me, but still I don't understand.

Yes @kinestheticlearning, as Brian said, the right map will be like

with these explicit "0"s ("0,0,0,(255-transparency)"). Now, your maps is writing a list (the four values of each pixel) inside those R, G and B slots.

The matter is (was strange to Brian and also to me) that the "switch to costume" block arrange this error, because this block puts "0" where there are "strange" values, as those lists.


Thanks @jguille2 for clarifying what Brian was saying. With the "0"s, in combination with the (for me, at least) unknown fact... (since visually everything has worked out okay) ...which you discovered, that the "Switch to costume" block actually 'took care' of any RGBA list by putting a "0" instead, I now understand.

To make the solution by you two a bit more elegant, a new (as explained here) block of a Reporter type is needed.


not really important

See it in project Media_Map_with_JS_block {the link will open it in editMode & noRun} within my "Output" sprite there you can see the custom block I made; it works, again, just fine, however it reports an error and I'd appreciate explanation for it. (I have tested the custom block on its own and it works just fine, so why it reports an error?)

EDIT: maybe this thread/topic should be split

For large lists, would it be faster to do something like this?untitled script pic (2)
That way, the program would not have to go through the entire list.

What you said is pure gold.

Thank you so much!

EDIT: I don't know - so I will ask you - does not the "KEEP ITEMS FROM <>" need to go through the entire list?

Because it's being given a bad input. My guess is that the variable R,G,B,A has no value.

Yes. There's a new primitive block FIND FIRST that does what you want.

Yes, I just noticed that it does. However, I'm guessing the simple < true > block for each item evaluates faster than an if-then-else statement.

It really is that much faster? Wow.