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

Case expressions #664

Open
fintara opened this issue Oct 9, 2023 · 1 comment
Open

Case expressions #664

fintara opened this issue Oct 9, 2023 · 1 comment
Assignees
Labels
Feature Request Feature Request or Enhancement P Language Enhancement New language features for P

Comments

@fintara
Copy link

fintara commented Oct 9, 2023

I want to suggest a language enhancement - "case expressions" (or maybe "switch expressions").

I use Haskell and other functional languages and I really miss this feature. :) It makes code simpler (shorter) and safer.
In P it will probably be used primarily for enums, but this feature doesn't need to be limited just to them: it can be further enhanced with pattern matching, if not - it can still be a "glorified" if-then-else. (More so, in P if-then-else is a statement, and this will be an expression.)

I have found myself to analyse a given enum value quite often. Please consider the following example:

enum Color {
    Red, Yellow, Green
}

fun colorToString(color: Color): string {
    if (color == Red) { return "Red"; }
    else if (color == Yellow) { return "Yellow"; }
    else if (color == Green) { return "Green"; }
    else { assert false, "Unhandled branch in colorToString"; }
}

It seems to be the only possible approach currently, and for me the main problem (apart from being a bit too verbose) is the necessity of the "else" branch. It's also a runtime error for something that can be caught at compile time.

With "case expressions", the same function would look like this:

fun colorToString(color: Color): string {
    return switch (color) {
        case Red: "Red"
        case Yellow: "Yellow"
        case Green: "Green"
    }
}

And when the enum changes (a term is added or removed), a descriptive error can be produced at compile time.

Of course, the syntax may be changed, I've tried to stay "close to P" :)

Moreover, the "handler" for each case could be a function, just like the case analysis in receive (from user's perspective it looks somewhat similar to this, which is interesting). However, in that case it would still be beneficial to have this "short syntax" like in the example above.

@ankushdesai
Copy link
Member

Thanks @fintara for this suggestion!

I agree this would simplify the life of P users. I have added this to our features list and will definitely address it in the new future.

@ankushdesai ankushdesai self-assigned this Oct 9, 2023
@ankushdesai ankushdesai added P Language Enhancement New language features for P Feature Request Feature Request or Enhancement labels Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Feature Request or Enhancement P Language Enhancement New language features for P
Projects
None yet
Development

No branches or pull requests

2 participants