[go: up one dir, main page]

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

Discussion: Improve code operators #1597

Open
AndreasArvidsson opened this issue Nov 13, 2024 · 0 comments
Open

Discussion: Improve code operators #1597

AndreasArvidsson opened this issue Nov 13, 2024 · 0 comments

Comments

@AndreasArvidsson
Copy link
Collaborator
AndreasArvidsson commented Nov 13, 2024

The problem

Implementing operators in a programming language today is very verbose. This is due to the fact that each operator is its own action. This creates a lot of boiler plate and there is no easy overview of the operators in a particular language.

eg 97 lines in java :

def code_operator_lambda():
actions.insert(" -> ")
def code_operator_subscript():
actions.user.insert_between("[", "]")
def code_operator_assignment():
actions.insert(" = ")
def code_operator_subtraction():
actions.insert(" - ")
def code_operator_subtraction_assignment():
actions.insert(" -= ")
def code_operator_addition():
actions.insert(" + ")
def code_operator_addition_assignment():
actions.insert(" += ")
def code_operator_multiplication():
actions.insert(" * ")
def code_operator_multiplication_assignment():
actions.insert(" *= ")
def code_operator_exponent():
actions.insert(" ^ ")
def code_operator_division():
actions.insert(" / ")
def code_operator_division_assignment():
actions.insert(" /= ")
def code_operator_modulo():
actions.insert(" % ")
def code_operator_modulo_assignment():
actions.insert(" %= ")
def code_operator_equal():
actions.insert(" == ")
def code_operator_not_equal():
actions.insert(" != ")
def code_operator_greater_than():
actions.insert(" > ")
def code_operator_greater_than_or_equal_to():
actions.insert(" >= ")
def code_operator_less_than():
actions.insert(" < ")
def code_operator_less_than_or_equal_to():
actions.insert(" <= ")
def code_operator_and():
actions.insert(" && ")
def code_operator_or():
actions.insert(" || ")
def code_operator_bitwise_and():
actions.insert(" & ")
def code_operator_bitwise_and_assignment():
actions.insert(" &= ")
def code_operator_increment():
actions.insert("++")
def code_operator_bitwise_or():
actions.insert(" | ")
def code_operator_bitwise_exclusive_or():
actions.insert(" ^ ")
def code_operator_bitwise_left_shift():
actions.insert(" << ")
def code_operator_bitwise_left_shift_assignment():
actions.insert(" <<= ")
def code_operator_bitwise_right_shift():
actions.insert(" >> ")
def code_operator_bitwise_right_shift_assignment():
actions.insert(" >>= ")
def code_self():
actions.insert("this")
def code_operator_object_accessor():
actions.insert(".")

My implementation - Talon list with typed class

My solution to this is to use a Talon list. The benefit with this is that operators that is not supported by the language is not speakable and its implementation is quite compact. I even added a class so I could get typed operators in my list.

eg 23 lines in java: https://github.com/AndreasArvidsson/andreas-talon/blob/ab634074d15197eca86f7bff5c0fb549799faa46/languages/java/java.py#L12-L35

Pros

  • Terse / compact
  • Only supported operators in the grammar
  • The keys are typed so you get code completion and can't make a typo
  • Can be implemented one language at the time

Cons

  • Spoken form is defined in python instead of a Talon file
    In my implementation I just use the class fields as the spoken form. For community we could either default to that and have a override map or we could define all the spoken forms in a map from the start.
  • A Talon list file doesn't lend itself well to optional grammar. eg this operator can be said in six different ways:
    (op | logical | bitwise) (ex | exclusive) or: user.code_operator_bitwise_exclusive_or()

The middle ground solution

One way to do it would be to keep the community Talon files but instead of each operator calling a separate action we just have a single code_operator(id: str) that is used by all the operators. We would then per language have something very similar to the operator's class in my example that just defines each operator's value but don't assign them to a Talon list. Instead the class is used by an action.
eg: (op | logical | bitwise) (ex | exclusive) or: user.code_operator("bitwise_exclusive_or")

Pros

  • No spoken forms are defined in python
  • We keep the flexibility of the Talon files
  • Almost as compact per language as my implementation

Cons

  • We still need to use the operator tags and the multiple Talon files
  • Operators that are not supported by the language might be available in the grammar
  • Needs to be implemented in all languages at the same time

Summary

I'm very happy with my implementation for my own needs, but for community I think the middle ground solution is the best. That would basically involve:

  1. Create a dict/class for each programming language with its operators
  2. Implement the new operator's action
  3. Replace all the old calls to the operator's actions in the Talon files with the new action

Any opinions? @phillco @knausj85 @nriley

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

No branches or pull requests

1 participant