Syntax Validation and Program Execution #24
meganindya
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Music Blocks 1.0 has inconsistencies w.r.t. attachment of value blocks to other blocks (as parameters). Some blocks restrict the type of value blocks they can attach, others don't. Also, the program is more-or-less untyped. Sure there is a somewhat difference between String and Number types, but sometimes Strings are also parsed as Numbers.
The prototype of MB 2.0 I've been working on is strictly typed — there are 5 primitive types: Integer, Float, Character, String, and Boolean. Some elements (underneath, which will be equivalent to blocks in the UI) may support parameters of multiple types but, yet then, the static nature is preserved. This identifies some problems that don't show up in MB 1.0 until an erroneous case is encountered during execution.
This leads to the following discussions:
Syntax Validation
An invalid syntax can arise out of 2 possibilities: Missing parameter/s, and Invalid Parameter/s.
One way to avoid invalidity of parameter's can be achieved during attachment itself. There are indeed ambiguous cases when there is type overloading, but that can be handled too. Basically, the user wouldn't be able to attach an invalid value block. But, this can create trouble in overloading cases. Say, for example, the add block can take 2 Integers, 2 Floats, 1 Integer and 1 Float, or 1 String and 1 Integer, and the return type will be Integer, Float, Float, String, respectively. If the add block is attached, before attaching value blocks to it, as a parameter which only accepts an Integer, the variation is restricted to only the first possibility in the sentence before. In another case, say, a Float and an Integer is attached to the add block first, such that its return type is Float, the add block can no longer be attached as parameter where an Integer is expected. This seems logical to follow, but can be counter intuitive without prior knowledge.
So, should we take this approach? Or, do we let the user apply any permutation, and the type validity check is deferred until the runtime?
Execution
Some blocks may take default values and keep executing (as in MB 1.0) in case of invalid parameters. In this case, the program technically fails silently, which I think is counter intuitive too. However, some blocks will require the values to run.
If we think of a syntax validation before executing the program, there are 2 possibilities: Syntax Validity Check before executing, or Dynamic Syntax Validation (analogous to syntax-highlighting in modern text-editors) during designing itself. In either case, visual cues may be provided to the user to suggest that something is wrong in the syntax. However, in the first case the validation delays the execution depending on the complexity of the validity check. In the second condition, the delay is distributed; every time a change is made to the syntax, the validation is tested for that case. This one is related to the previous section about strict attachment.
Syntax Invalidity due to missing parameters are inevitable. So there is another question: do we prevent the program from running until the entire syntax is valid, or we let it run (with or without silent errors) until an erroneous case is encountered?
Beta Was this translation helpful? Give feedback.
All reactions