Open sebllll opened 4 years ago
Some kind of visual syntactic sugar over this maybe?
Imagine renaming the if regions to something like "case". Instead of the Cond node there might be a "match"/"switch" region surrounding the "case" regions which returns the output of the first true case (short-circuiting evaluation) or Default if no case is true.
A number of the links should be able to be eliminated with a special region form instead.
Many details to figure out of course...
Anyway with an implementation of Cond I don't think that's all that bad.
Some thoughts on more elaborate visual constructions involving nested regions:
When looking at how pattern matching is usually have two parts: 1) Match pattern/condition 2) Expression to be executed if the pattern is matched
In the match pattern you can also do deconstructing/mapping of the value being matched into other values that are the input for the corresponding expression.
Let's say there was a match region containing case regions which each has two regions/parts - condition and expression, the condition decides if the expression will run.
Having a condition region above an expression region makes sense in a data flow way (data flowing down) but might make it harder/more cluttered to make links into the expression part.
A case region with a condition part on the left and expression on the right would make it easier to cleanly have incoming links but make everything wider.
(pictures needed)
Somehow my above screenshot holds up quite well when trying to think of custom visual forms as long as can avoid needless execution of the node graph.
In F# you also have exhaustive pattern matching which will warn you if your cases don't cover all of the input space if you don't have a default/wildcard.
As switch-case constructs are a common and useful coding pattern, a way to have those represented in the language would be nice.
Imho this is mostly a quest on finding a good visual representation for that.
This is a way to patch such a pattern today, without such a language feature, but it is a) tedious and b) missing constructs like
default:
,goto
.when
(pattern matching)i'd say, one could work around all those things today with a chain of if's, but the patch gets more unreadable with increased complexity.
also, in C# 8.0 there's this new switch expression syntax which might be of interest in that context.