Custom Block Parameters and Default Values

[Turgut Guneysu]

Hi John,

This is probably NOT a bug, but I wanted to check on its workings:

A custom block with input parameters with corresponding Labels are defined, and initial values are assigned to those parameters:

Execution of this block produces correct output if the parameters are EXPANDED:

but incorrect output if NOT expanded:

My Question is:

I thought the parameters and their values defined for a function represented DEFAULT values for those parameters.

So unless the function block is EXPANDED, the default is NOT applied !

I find that counter to what I expected.

My Expectation was: Expanded or not, the defaults should have applied, OR any other values supplied should be applied.

On the other hand:

Following type of custom block definition with parameters but NO Labels works OK:

but it does NOT give you and option to EXPAND or not.

What am I not understanding ?

RELATED Custom Block ISSUE:

When a Custom Block definition is selected to be DELETED from the left side My Blocks menu,

the deletion leaves the actual blocks used in code intact.

In SNAP! all deleted custom blocks in use are deleted from code as well.

Just pointing it out as a different behavior, in case of future joined operations of the two environments.

TG

[John Maloney]

Optional parameters an undocumented not fully supported feature. There is no UI for creating functions with optional parameters, although one can edit the textual code for a MicroBlocks project or library to declare optional parameters. I’m guessing you must have done that. MicroBlocks does use this feature in a couple places in the MicroBlocks libraries.

We don’t plan to add UI and compiler support for this mechanism, since it is only rarely needed and could be confusing to those just learning about functions. In most cases, it is better to use a normal, non-optional parameter with a default value (which is supported).

But since you asked…

For advanced users like you who really want to use an optional parameter and don’t mind editing text code, the thing to know is that, when a block with optional parameters is collapsed, those parameters are not passed to the call at all (as opposed to the default value being passed). Thus, the implementation of a function with optional parameters must check the number of arguments actually passed and only use those parameters that were actually supplied.

Here is an example from the NeoPixel library:

to neoPixelAttach number pinNumber optionalHasWhite {
  hasWhite = false
  if ((pushArgCount) > 2) { hasWhite = optionalHasWhite }
  if (or (_np_pixels == 0) (number != (size _np_pixels))) {_np_pixels = (newList number)}
  fillList _np_pixels 0
  '[display:neoPixelSetPin]' pinNumber hasWhite
}

This uses a local variable, ‘hasWhite’, whose initial value is set to false, the desired default value. If there are more than two arguments ((pushArgCount) > 2), then ‘hasWhite' is set to the value of the optional third argument thus overriding the default.

‌

[Bernat Romagosa]

Hi, John. We do offer support for additional parameters at the UI level, you just need to suffix a label with a colon, and the first pair of label + parameter after it will be made optional.

Since they can be created from the UI I think we should someday take a look at this bug. Not urgent, though

[John Maloney]

Whoa, what you suggest is a (clever!) hack, but not the intended behavior! However, even knowing the hack, this feature should only be used by experts because when the block is not expanded you’ll get an undefined value for the missing parameter (and it could potentially even crash the VM). But I agree, at some point we might improve the IDE (both the UI and the compiler need to be changed) to make this a real feature.

[Bernat Romagosa]

Haha, funny! I actually ran into this way to create optional parameters accidentally when I tried to add a label that ended with a colon. I’m glad to know this isn’t intended, though, because colons are useful for certain types of parameters.

[John Maloney]

Fixed by filtering out colons in user-supplied keywords in a block definition. This avoids accidentally creating a block with optional parameters.