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

Add a way to use comparison primitives #132

Open
Tracked by #79
Ailrun opened this issue Nov 15, 2019 · 3 comments
Open
Tracked by #79

Add a way to use comparison primitives #132

Ailrun opened this issue Nov 15, 2019 · 3 comments
Assignees
Labels
discussion This issue or pull request is under a discussion enhancement New feature or request

Comments

@Ailrun
Copy link
Member

Ailrun commented Nov 15, 2019

Is your feature request related to a problem? Please describe.
Currently, it is not possible to use comparison primitives easily. This issue is to discuss ways in which it would be nicer to use, implement, etc.

Describe the solution you'd like
In order to use comparison primitives, this language needs at least one of the following.

  • Primitive pattern matches
  • Integer2Boolean conversion
  • Primitive if primIf (which uses an integer as its condition)

For each of these, implementation of higher level if (n <? 3) then t else f changes a lot.

  • Primitive pattern matches
    The expression would be match n < 3 with 1 -> t; 0 -> f;.
  • Integer2Boolean conversion
    It would be match integer2Boolean (n < 3) with C{1;0} -> t; C{2;0} -> f;
  • Primitive if primIf
    It would be primIf (n < 3) t f
@Ailrun Ailrun added the enhancement New feature or request label Nov 15, 2019
@Ailrun Ailrun self-assigned this Nov 15, 2019
@Ailrun
Copy link
Member Author

Ailrun commented Nov 15, 2019

I think the language needs both primitive pattern matches and the integer2Boolean conversion.
However, the reasons for them are unrelated with each others. For primitive pattern matches, the reason is because it is more preferable to use pattern matching than multi-way ifs, since it should require at most one table-jump, and no more comparison. For the other one, it is the one required to implement if.

@Ailrun Ailrun mentioned this issue Nov 17, 2019
27 tasks
@Ailrun
Copy link
Member Author

Ailrun commented Nov 26, 2019

FYI: The reason why I think Integer2Boolean is better is that the way makes implementation more consistent. By 'implementation', I mean the ones for if for primitive conditions (like >?, >=?, ...) and for non-primitives (like is_even, is_in, ...). If I implement primIf, then two cases would use different underlying syntaxes after desugaring. (One uses primIf, and the other uses match)

@Ailrun Ailrun added the discussion This issue or pull request is under a discussion label Nov 26, 2019
@Ailrun
Copy link
Member Author

Ailrun commented Apr 26, 2020

Or maybe... adding boolean2primInt is better idea.
It still makes the impl. of the two cases consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This issue or pull request is under a discussion enhancement New feature or request
Development

No branches or pull requests

1 participant