<p>Block-based languages use individual &quot;jigsaw puzzle&quot; pieces of code that slot together to build up programs. Commonly the blocks have various obvious protrusions and depressions that make only some combinations of blocks physically able to couple, in order to prevent the formation of syntax or semantic errors. The incompatibility is sufficiently visible that the programmer will understand they cannot put the block there, and not attempt it:</p>
<p><a href="https://i.sstatic.net/UzhZI.png" rel="noreferrer"><img src="https://i.sstatic.net/UzhZI.png" alt="A screenshot of the Scratch events toolbox showing a &quot;when I receive message&quot; block with a rounded top and a small trapezoidal protrusion below, and a &quot;broadcast message&quot; block with corresponding trapezoidal indent above and protrusion below." /></a></p>
<p>How can such a language prevent construction of <em>type</em> errors? Scratch uses rounded rectangles and flattened hexagons for its combined string/number/list and boolean types, with both the blocks and the slots they can be put in taking on these shapes, but we are already close to running out of distinguishable shapes at two:</p>
<p><a href="https://i.sstatic.net/116HX.png" rel="noreferrer"><img src="https://i.sstatic.net/116HX.png" alt="A screenshot of the Scratch operator toolbox, with two rounded blocks &quot;letter '1' of 'apple'&quot; and &quot;length of 'apple'&quot;, and a flattened hexagon &quot;'apple' contains 'a'&quot; block" /></a></p>
<p>Most languages have many more incompatible types than this even as built-ins. What mechanism can a block language use to represent and enforce type compatibility of values and expressions?</p>

<types><block-based-languages>
How can a block-based language represent type-compatibility of blocks?
CC BY-SA 4.0
2023-05-22T23:48:15.440Z
What do you mean by running out of distinguishable shapes?
You could have any number of "key" and "lock" patterns on adjacent shapes.
Bruce Adams
CC BY-SA 4.0
2023-05-22T23:54:00.190Z
It is true that you can always make new shapes that are distinguishable *to the machine*, but it's *a person* who has to tell them apart at a glance or identify what else is the same shape. I think those are quite limited, but if not then that's an answer.
Michael Homer
CC BY-SA 4.0
2023-05-23T00:03:24.430Z
I thought the whole point of visual languages like this is that the human brain is good at identifying shapes at a glance. Just consider for a start +ov*^$ shaped protruberences. Then add colour and put them in a row to mean different. The harder issue is making them meaningful and controlling clutter.
Bruce Adams
CC BY-SA 4.0
2023-05-23T00:30:35.247Z
That sounds like the start of an answer! But yes, the hard part is the hard part.
Michael Homer
<p>Rewrite of <strong>@kaya3</strong> answer.</p>
<p>You can change the mouse shape when the block is above the not allowed socket.</p>
<p>Like this:</p>
<p><a href="https://i.sstatic.net/fyAf3.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/fyAf3.png" alt="enter image description here" /></a></p>
<p>And the block doesn't drop in this socket.</p>

CC BY-SA 4.0
2023-05-25T08:38:49.563Z
2023-05-26T08:58:42.067Z
2023-05-26T08:58:42.067Z
чистов_n
CC BY-SA 4.0
2023-05-25T11:13:14.227Z
Adding to this, perhaps graying out everything except the areas where you are allowed to drop the block
Jacob
<p>One idea might be using symbols or icons that need to match. For example, you could have</p>
<pre><code>,-------------------------------------,
| Letter (     ) of (       )  |
`-------------------------------------'
</code></pre>
<p>into which you can slot</p>
<pre><code>( 1  )

( apple  )

,-----------------------------------,
| (     ) contains (       ) ? |
`-----------------------------------'
</code></pre>
<p>These icons could then be highlighted or flashing if the user tries to insert an expression into a slot with a different type.</p>

CC BY-SA 4.0
2023-05-25T10:34:13.260Z
2023-05-25T10:34:13.260Z
Jasmijn
<p>One option is to change the visual representation depending on the context. Type compatibility matters while you are choosing where to move an expression block to (i.e. during drag-and-drop), so you could wait until the user selects a block before you visualise where that block can fit.</p>
<p>For example, expressions might all have the same shape, but while the user is dragging an expression block, you draw a &quot;not allowed&quot; symbol  or a &quot;locked&quot; symbol  in the sockets where that expression cannot be dropped. Perhaps you could also draw a different symbol in the sockets where it can be dropped.</p>
<p>Alternatively, you could have the shapes all be the same, but change the shapes of incompatible sockets only while dragging an expression. Perhaps all expression blocks are round, but when the user drags an expression block, the incompatible sockets become pointy.</p>
<p>This has the drawback that this information won't be visible all the time. But the more information you want to show at once, the harder it will be to show everything in a legible way. By hiding some information when it is not relevant, the information you do show becomes easier to distinguish.</p>

CC BY-SA 4.0
2023-05-22T23:01:46.550Z
2023-05-22T23:01:46.550Z
kaya3
# How can a block-based language represent type-compatibility of blocks?
Posted by: username_0 on 2023-05-22
Block-based languages use individual "jigsaw puzzle" pieces of code that slot together to build up programs. Commonly the blocks have various obvious protrusions and depressions that make only some combinations of blocks physically able to couple, in order to prevent the formation of syntax or semantic errors. The incompatibility is sufficiently visible that the programmer will understand they cannot put the block there, and not attempt it:

[![A screenshot of the Scratch events toolbox showing a ](https://i.sstatic.net/UzhZI.png)](https://i.sstatic.net/UzhZI.png)

How can such a language prevent construction of *type* errors? Scratch uses rounded rectangles and flattened hexagons for its combined string/number/list and boolean types, with both the blocks and the slots they can be put in taking on these shapes, but we are already close to running out of distinguishable shapes at two:

[![A screenshot of the Scratch operator toolbox, with two rounded blocks ](https://i.sstatic.net/116HX.png)](https://i.sstatic.net/116HX.png)

Most languages have many more incompatible types than this even as built-ins. What mechanism can a block language use to represent and enforce type compatibility of values and expressions?
**Tags:** types block-based-languages
> **Comments:**
> **username_1**: What do you mean by running out of distinguishable shapes?
You could have any number of "key" and "lock" patterns on adjacent shapes.  
> **username_0**: It is true that you can always make new shapes that are distinguishable *to the machine*, but it's *a person* who has to tell them apart at a glance or identify what else is the same shape. I think those are quite limited, but if not then that's an answer.  
> **username_1**: I thought the whole point of visual languages like this is that the human brain is good at identifying shapes at a glance. Just consider for a start +ov*^$ shaped protruberences. Then add colour and put them in a row to mean different. The harder issue is making them meaningful and controlling clutter.  
> **username_0**: That sounds like the start of an answer! But yes, the hard part is the hard part.  
---
## 3 answers
### Answer by username_4 on 2023-05-25. Score: 9
One idea might be using symbols or icons that need to match. For example, you could have
,-------------------------------------,
| Letter (     ) of (       )  |
`-------------------------------------'

into which you can slot
( 1  )

( apple  )

,-----------------------------------,
| (     ) contains (       ) ? |
`-----------------------------------'

These icons could then be highlighted or flashing if the user tries to insert an expression into a slot with a different type.
---
### Answer by username_5 on 2023-05-22. Score: 4
One option is to change the visual representation depending on the context. Type compatibility matters while you are choosing where to move an expression block to (i.e. during drag-and-drop), so you could wait until the user selects a block before you visualise where that block can fit.

For example, expressions might all have the same shape, but while the user is dragging an expression block, you draw a "not allowed" symbol or a "locked" symbol in the sockets where that expression cannot be dropped. Perhaps you could also draw a different symbol in the sockets where it can be dropped.

Alternatively, you could have the shapes all be the same, but change the shapes of incompatible sockets only while dragging an expression. Perhaps all expression blocks are round, but when the user drags an expression block, the incompatible sockets become pointy.

This has the drawback that this information won't be visible all the time. But the more information you want to show at once, the harder it will be to show everything in a legible way. By hiding some information when it is not relevant, the information you do show becomes easier to distinguish.
---
### Answer by username_2 on 2023-05-25. Score: 3
Rewrite of **@kaya3** answer.

You can change the mouse shape when the block is above the not allowed socket.

Like this:

[![enter image description here](https://i.sstatic.net/fyAf3.png)](https://i.sstatic.net/fyAf3.png)

And the block doesn't drop in this socket.
> **Comments:**
> **username_3** (2023-05-25): Adding to this, perhaps graying out everything except the areas where you are allowed to drop the block  
---
