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

Rename && and || to ands and ors #240

Closed
gilch opened this issue Oct 29, 2023 · 1 comment · Fixed by #246
Closed

Rename && and || to ands and ors #240

gilch opened this issue Oct 29, 2023 · 1 comment · Fixed by #246

Comments

@gilch
Copy link
Owner

gilch commented Oct 29, 2023

The PandoraHissp Snake game in the readme already does this because the usual symbols are so awkward in EDN. I'd be able to remove that line.

This is a very breaking change, but an easy one to fix.

I'd have called them and and or to begin with, but Lissp doesn't munge Python's reserved words, so these were already taken. I got the && and || alternative naming from C, but ands and ors feel more like Python. The pluralization makes sense when you consider that they're multiary, unlike the strictly binary Python operators they're based on.

@gilch
Copy link
Owner Author

gilch commented Oct 29, 2023

Less obviously a good idea, but this reasoning and naming convention, plus the string macro technique from #198 allows for more multiary replacement macros. For example, +s for multiary addition.

I find the use of the star-imported operator suite quite legible, but e.g., add is strictly binary, which feels less Lispy. Maybe we don't need this. add is a lot nicer than XY#.#"X+Y", but once a formula gets even a little complicated, the injection approach wins out. Star imports are also kind of a bad idea in larger projects.

Why not just name it + then? Well, + is really supposed to be a function. #84 removed car and cdr macros because those not being functions was confusing. You should be able to pass + to higher-order functions like map or reduce. Macros don't work like that. You could define or import one with the same name as the macro (one of the features of having a separated macro namespace), which allows the macro to shadow the function when in the function position. But then they probably don't quite work the same way. An alternative would be to just define the function in the prelude. But it kind of already does that by star importing from operator. +s doesn't have this baggage.

Python expression replacements are tier 2 in the inclusion criteria #154, so there is a case for adding them.

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

Successfully merging a pull request may close this issue.

1 participant