Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Quest] switch statement as first class citizen #14

Open
sebllll opened this issue Jun 19, 2020 · 2 comments
Open

[Quest] switch statement as first class citizen #14

sebllll opened this issue Jun 19, 2020 · 2 comments
Labels

Comments

@sebllll
Copy link

sebllll commented Jun 19, 2020

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)
image

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.

@gregsn gregsn added the quest label Jun 19, 2020
@beyon
Copy link

beyon commented Jun 23, 2020

Some kind of visual syntactic sugar over this maybe?
bild

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.

@beyon
Copy link

beyon commented Jun 25, 2020

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.

  • Does the condition only have a boolean output to decide if the expression should run or do you also want to allow transforming (mapping) the input there and forward it to the expression? Is there any visual benefit to do it like many text based languages do?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants