You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
Create a dict/class for each programming language with its operators
Implement the new operator's action
Replace all the old calls to the operator's actions in the Talon files with the new action
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 :
community/lang/java/java.py
Lines 93 to 190 in c5f32ad
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
Cons
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.
community/lang/tags/operators_bitwise.talon
Line 11 in 8eb2f32
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
Cons
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:
Any opinions? @phillco @knausj85 @nriley
The text was updated successfully, but these errors were encountered: