One tweak for "make a block" screen

Feature Requests Snap! Feature Requests
1

Make so that when you type a certain character like [], (), or <> it automatically turns it into an input based on the character given, in the Make a block screen.

For example, repeat [str] (repetitions) times results in:
{(@+ repeat @+ (str) @+ (repetitions #)@+ times @+ :: operators } :: control hat

Maybe I'm going to give some explanation about each of the shortcuts:

  • [input] results in a text input.
  • (input) results in a number input.
  • <input> results in a boolean input.
  • {input} results in a C-shaped input.
  • input... results in a list input.

Any thoughts?

2

yeah, I like this, but I would also want {<>} for predicates, {{}} for commands in rings, and {()} for reporters.

3

I like the idea of being able to specify the type of an input up front, but I don't like the specific notation proposed, because those bracketing punctuation characters are things users want to use as text, and I don't want them to have to backslash them or anything like that.

At one point in our history, you couldn't name a block
INCREASE SIZE BY ( ) %
because that percent at the end would make an input slot with a null name. We fixed that pretty quickly, but it required special-casing a percent sign not immediately followed by an alphameric.

I get that this is what Snapblocks does, but not all users know about Snapblocks.

For those reasons, I think a better syntax is to follow the input's name with the same punctuation character that users already know from the type hint notation in the Block Editor:
%anyType
%number#
%list:
%Boolean?

For variadic inputs, "..." after that punctuation, so
%anyVariadic...
%numberVariadic#...
%listVariadic:...
%BooleanVariadic?...
I think we should display typed variadic input hints that way, too.

Procedure-type inputs are a little trickier because users outside Greece don't have lambdas on their keyboards, and users in Greece have to be able to distinguish an input name that naturally ends in ℓ (i.e., λ) from a procedure-type input. One thing we could do is follow the old Lisp convention of using \ to mean λ (because it sort of looks like a lambda), but that would confuse people accustomed from other languages to think \ quotes the following character. We could use \\ for lambda, I guess. Or we could use &, which is also kinda lambda-shaped. I propose that last one.

To distinguish among types of procedure inputs, we could use a character after the ampersand. For that purpose we could even use letters, because after an ampersand there's no ambiguity.
%reporter&
%predicate&?
%inlineCommand&u (mnemonic for the tab at the bottom)

%cShaped&c
%anyUnevaluated&-
%BooleanUnevaluated&?- (also accept &-?)

And of course variadic versions of all those,
%anyUnevaluatedVariadic&-...
and so on.

I'm pretty sure we could accept any rearrangement of type modifiers after an input name, e.g.,
%BooleanUnevaluatedVariadic-?...&
except that letters can't come first, so no
%cShapedc&

(Note that this proposal uses letters only for their shape, not to abbreviate a type name such as %n for numeric, so there's no issue about internationalization.)

Not saying we're going to do this any time soon, or at all, but if we do, we should imho do it this way.

4

same issue as

(escaping a backslash)

5

I agree with your argument about how the snapblocks syntax is not very good for snap, however I do want to point out that not a lot of people would even know they can type inputs directly into the make a block dialog because, I'm pretty sure, it's undocumented, so the people who would use it, would probably already know snapblocks, or more likely, scratchblocks.

Of course the snapblocks syntax is actually also designed to mimic what the inputs visually look like so that it can be easy to figure out. Round inputs are round brackets, rectangle inputs are rectangle brackets, angled inputs are angled brackets.

I agree with this, as this already builds upon the current system (which I think is better than implementing new systems). My only problem is that sometimes I like to add a question mark to the end of my boolean inputs (so it shows up in the variable), so I think adding a separator, like another % before the type, would be much better.

Actually, thinking about it now, one way you could use the snapblocks syntax (that is visually similar to what is shown in the blocks) is by having the brackets after the %, like %(number), %[any], and %<boolean>. That way it can be clear that this is an input (based on the %), so it still allows you to use these brackets as labels. Oh, and adding this could also allow you to use spaces in the input when making the name instead of having to add a space after creating the block.

6

Yeah, that'd work too. Although not so well for lists, C-shape, etc., which don't have natural bracket shapes.

Good point about ?, though.