gilch
commented
10 months ago 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.
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
andandorto begin with, but Lissp doesn't munge Python's reserved words, so these were already taken. I got the&&and||alternative naming from C, butandsandorsfeel more like Python. The pluralization makes sense when you consider that they're multiary, unlike the strictly binary Python operators they're based on.