Standard Language Specification (abridged)

[meganindya]

To my understanding, Music Blocks is a programming language that happens to pack drawing and music features. But, the programming aspects don't seem to have a strong foundation. I think we were restricted a lot by the structure previously as these features were afterthoughts. But, with the new program structure tree, a lot can be built robustly.

I strongly believe types should be standardized and whether it should be static or dynamic needs to be discussed. Even though the code will effectively transpile to JavaScript to run on the browser, we still have features JavaScript (or for that matter any language) doesn't support.

My opinion is that a consistent language pattern will bring us heavy performance gain and make the programs deterministic. Following is my idea of how the language should be.

Building Blocks

Data Types

• Integer
• Float
• Character
• String
• Boolean

Identifiers

Since this is a Visual Programming Language the shape of the identifier will not conflict and will be preserved and so any supported character can technically be part of it, but I think we need to enforce some constraints for future transpilation support (e.g. export to another programming language).

I think alphanumeric in addition to underscore and blank space, with the first character not being a numeric digit should be used. If and when export is up, maybe we can replace the blank spaces by underscores.

Conditionals

• If
• If-Else
• Switch Case

Loops

• For
• While
• Do-While
• Duplicate

Flow

• Backward
• Break
• Continue
• Label (this one is debatable; I've come across situations while using nested loops in Java and C++ when a break label or goto label was actually an elegant solution; goto still must be avoided but a break label and a continue label could be useful, although it is an obscure case)

Expressions

Decimal Algebra

• Add
• Subtract
• Multiply
• Divide
• Modulus
• Exponent

Boolean Algebra

• Equals (type checking case like === is debatable)
• Greater than (Greater than or equal to is debatable)
• Less than (Less than or equal to is debatable)
• Conjunction (∧) (and, as in &&)
• Disjunction (∨) (or, as in ||)
• Negation (¬) (not, as in !)
• Bitwise AND (as in &)
• Bitwise OR (as in |)
• Bitwise NOT (as in ~)
• Bitwise XOR (as in ^)
• Left shift (as in <<)
• Right shift (arithmetic or signed) (as in >>)
• Right shift (logical or unsigned) (as in >>>)

Subroutines

• Main (start)
• User-defined (action)
• Return
• Call subroutine
• Call subroutine with arguments
• Collect returned arguments from subroutine call (calculate)

This brings up a question of whether we want the subroutines to be statically-typed (because what does a void type subroutine return?).

Asynchronicity (and Interrupts)

• Forever
• Wait for
• Exit (stop)
• Event Listener
• Event Signal Dispatcher
• Event Dispatcher (this is debatable given the presence of the previous)
• Delay (time accuracy is subjective)

Standard Library

Data Structures

Types (and dynamicity) are debatable.

Array

• Initialize
• Add at location
• Remove from location
• Sublist
• Length
• Reverse
• Sort

Stack (Linear heap)

• Push
• Pop
• Poll
• Clear
• Load all
• Size

Dictionary (Map)

• Add pair
• Remove key
• Update key
• Add all
• Get keys

Math

General

• Constants (π, e, etc.)
• Absolute
• Negate
• Round
• Ceil
• Floor
• Random (uniform)
• Random (normal or Gaussian)
• Square root
• Logarithm (decimal)
• Logarithm (natural)
• Euclidean distance

Trigonometry

• Degrees
• Radians
• Sine
• Cosine
• Tangent
• Sine inverse
• Cosine inverse
• Tangent inverse

String

• Append
• Substring
• Slice
• Reverse
• Trim
• Parse to Number
• Parse to Array

Miscellaneous

• Print
• Comment

Functional Programming

• Map
• Filter
• Reduce

Some of these are indeed a bit advanced, but my opinion is that Music Blocks could be more than what it is.

[walterbender]

This looks great. I don't have an issue with any of the more advanced functions.
In the current implementation, boxes are really just dictionary entries.
I do think until is a useful loop that has its place beside while.

[meganindya]

What are your opinions on static-typing? A lot of my programming experience has been in Java and C/C++. I’ve been using Python and JavaScript only in the recent few years. There are things I appreciate - simple implementation of things like dynamic lists (vectors), dictionaries (maps), dynamic return types. But, I’ve been finding these same features very inconsistent lately. This is the reason I prefer TypeScript, and use type hints in Python as much as possible.

[walterbender]

If we use Python, we can use Pydantic to define (and check) schemas. It works very well and leads to more consistent code.

[meganindya]

I understand that. I meant the type-constraint in Music Blocks itself. I guess the language specification is independent of the language it is implemented in.

e.g. What do you think about static-typed actions? Say, I want an action to return a value. Should or shouldn't I need to specify the return type in the action block itself? (The action needs to necessarily return a value of the said type in such case)

[walterbender]

Yes. I think we should static types in Music Blocks itself.

[meganindya]

Currently repeat block isn't exactly a for loop, in the sense that you do not have access to the counter variable.

If we have more of a for ... in block, you could iterate over strings as well, getting the index and the indexed character in each iteration.

[pikurasa]

Has there been consensus on this?

Personally, repeat works well from my perspective. But I've never really experienced much else, not really thought too much of the implications for music.

[pikurasa]

This list is super-helpful.

We should label which of these are high shelf, and which are low shelf, as well.