RichoM
commented
4 years ago Interesting analysis. I'm glad you're giving this some thought. There is much to improve in this area.
Pins could have their own type Pin.
Yes, definitely.
If Uzi doesn't allow numbers as pins, then this is a clear case that pins should have their own type. I could find some arguments and use-cases for insisting to have pins with type Number, e.g. to iterate a range over a range of pins, but in my personal opinion this is not that a strong argument, especially pedagogically.
Actually, Uzi treats the pin names as just aliases for their internal number. So for the compiler it doesn't matter if you write 13 or D13, it will generate the exact same program in both cases.
That said, I don't think that we should design the block-based language following the same rules as the text-based language. In this case, I think you're right in that we should add the Pin type and make sure the types are checked strictly. I do, however, worry about the "iterate over a range of pins" use case but, as you said, it not a strong argument. And if we really need it we could add a block that creates a pin from an arbitrary number.
Pin values can take Numbers, although traditionally they also take Boolean states. I will investigate whether Blockly allows multiple types (but this is not a real problem).
I don't have a lot of experience with Blockly's type system but I believe it does allow multiple types. I agree it would be good to allow both Number and Boolean.
Tones are currently defined in-block with a dropdown list. If Tones would get their own block in the same way as Pins have, then they'd need to be with their own type Tone.
I made the distinction between "notes" and "tones" to allow to specify sounds by name and, eventually, I would like to display a small musical keyboard when clicking the dropdown (just like Snap! does it but maybe with more keys).
If we add the Tone block and type, as you suggest, we would be able to simplify the "Sound" blocks by removing the note vs tone distinction. That would be nice but I still think we should allow the user to specify the exact tone as a number. So maybe we can make these blocks accept both types Number and Tone.
This is perhaps where most confusion is (for me). Boolean blocks are coloured almost the same shade of blue as are Number blocks. I propose we change the color of Booleans (maybe green or yellow?).
Yes, absolutely. I never realized we don't have any green or yellow blocks. It just goes to show you how little thought I gave to the design of the blocks. Again, thank you for taking care of this.
kristiank
This is an attempt to review and discuss block types.
Statistics
Currently 34 blocks' outputs are set to the following types:
Number,Booleanandnull. Total 92 block inputs are checked for the same types.My first intuition is that the block's type could be reflected by its colour. Following is a discussion of blocks that I see as candidates for their own type, based on their function, colour and current type.
Pins vs Numbers
Pins could have their own type
Pin. Currently both output blocks and input slots for pins are red coloured but have typeNumber. Numbers otherwise are blue coloured. Pins seem to be defined as names in Uzi (A1, A2, D1, D2, etc). If Uzi doesn't allow numbers as pins, then this is a clear case that pins should have their own type. I could find some arguments and use-cases for insisting to have pins with type Number, e.g. to iterate a range over a range of pins, but in my personal opinion this is not that a strong argument, especially pedagogically.Pin values can take Numbers, although traditionally they also take Boolean states. I will investigate whether Blockly allows multiple types (but this is not a real problem).
Notes vs Tones
Tones are correctly marked and checked as numbers. Tones are currently defined in-block with a dropdown list. If Tones would get their own block in the same way as Pins have, then they'd need to be with their own type Tone.
Booleans vs Numbers
This is perhaps where most confusion is (for me). Boolean blocks are coloured almost the same shade of blue as are Number blocks. I propose we change the color of Booleans (maybe green or yellow?).
Understandably many blocks don't type check their inputs, these I can start fixing. E.g. the
repeat_timesblock has type checknullbut should beNumber.