6 ms·

Never bothered me. Move the function name into the parens, delete the commas. Nothing to it.

smabie 5y ago
Well, also give up infix functions/operators, operator precedence, readable equations, etc. Most Lisps have syntax anyways, in order to make the language less verbose. There's a reason people like syntax, because it is expressive.
- filoeleven 5y ago
  You don’t give up operator precedence, you just write it explicitly. Operator precedence is a consequence of implicit infix operator behavior. What is the value of this statement? 3 + 100 % 2 / 5 I’d like to have added a power calculation somewhere in there for illustration, but most general-purpose languages make that a function. It’s worth asking whether they ran out of infix symbols/syntax or chose a function for some other reason.
  - owl57 5y ago
    Probably the former. Python seems fine with infix **. But Python doesn't have pointers: C++ designers would have to invent something less conventional (not that they aren't famous for unconventional horrors, though).
- cellularmitosis 5y ago
  It seems like the infix issue would be a pretty simple modification to eval: if the first thing isn’t callable, try the second thing. But I’ve never seen this done, so it must be more complicated than I realize.
  - GavinMcG 5y ago
    The problem is that the first thing might be callable, and it might expect one or more arguments that could include functions. If your intention was to add something to the result of a function, but + was passed as input to that function, you wouldn't get what you expected.
    - cellularmitosis 5y ago
      Sure, if the first thing is callable, you always go with the default eval strategy, like in this case: (map - (quote (1 2 3))) I'm only talking about cases where the first thing isn't callable, but the second thing is: (3 + 1) It seems like this couldn't ever be a problem, because the only cases in which the infix strategy would be used are cases which would have been invalid programs anyway. Does that make sense?
- Jach 5y ago
  You don't have to give up on anything, that's the beauty of Lisp. Here's a library from 1993: https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix Though personally I don't particularly find (+ 1 2 3 4 5) less readable than 1+2+3+4+5, and since most of my programs don't have math expressions much more complicated than that, even without cmu-infix or alternatives (Maxima is great when you need to do real math, and for other related things I might as well link https://github.com/CodyReichert/awesome-cl#numerical-and-scientific https://github.com/CodyReichert/awesome-cl#numerical-and-sci...) I'd find the rest of the tradeoffs worth it, much like once I thought despite Python not having i++ or ++i it was still worthwhile. (In Lisp, by the way, one would use (incf i).)
- Blikkentrekker 5y ago
  > There's a reason people like syntax, because it is expressive. There are also many people who like the imperial system more than the metric system. Given that new languages with such syntax continue to be developed and that many express that they favor it, it is at best a personal taste, and at worst simply inertia. “conventional mathematical notation” was never designed; much like the imperial system, it organically grew and I find it somewhat arbitrary what operations receive an infix operation and what do not and it even depends on the language in some cases. That being said, I really do not favor `string-append` where `strapp` suffice. I especially do not favor `call-with-current-continuation` over `call/cc`.
- geocar 5y ago
  > Well, also give up infix functions/operators, False. All you really need is a bijection: McCarthy himself suggested f[x;y]<=>(f x y) and it seems reasonable (and it turns out to be actually useful!) to declare a domain of f where you permit xfy<=>(f x y) One of his students implemented this: http://i.stanford.edu/pub/cstr/reports/cs/tr/68/92/CS-TR-68-92.pdf http://i.stanford.edu/pub/cstr/reports/cs/tr/68/92/CS-TR-68-... which certainly has... other issues, but I don't agree infix syntax is incompatible with lisp. > operator precedence, readable equations, etc. Yes please. "readability" is usually given to mean "most people believe they can read it" and not something useful like "most people understand it fully", and nearly any reduction in typing that operator-precedence can offer can be obtained with a simpler rule (like right-of-left) and ordering. That is to say these things (in their usual meaning) have net-negative value to programs and programmers, are a frequent root-cause of bugs.
pjmlp 5y ago
Same here, never got why it should be such a big deal.

Well, also give up infix functions/operators, operator precedence, readable equations, etc. Most Lisps have syntax anyways, in order to make the language less verbose. There's a reason people like syntax, because it is expressive.

filoeleven 5y ago
You don’t give up operator precedence, you just write it explicitly. Operator precedence is a consequence of implicit infix operator behavior. What is the value of this statement? 3 + 100 % 2 / 5 I’d like to have added a power calculation somewhere in there for illustration, but most general-purpose languages make that a function. It’s worth asking whether they ran out of infix symbols/syntax or chose a function for some other reason.
- owl57 5y ago
  Probably the former. Python seems fine with infix **. But Python doesn't have pointers: C++ designers would have to invent something less conventional (not that they aren't famous for unconventional horrors, though).
cellularmitosis 5y ago
It seems like the infix issue would be a pretty simple modification to eval: if the first thing isn’t callable, try the second thing. But I’ve never seen this done, so it must be more complicated than I realize.
- GavinMcG 5y ago
  The problem is that the first thing might be callable, and it might expect one or more arguments that could include functions. If your intention was to add something to the result of a function, but + was passed as input to that function, you wouldn't get what you expected.
  - cellularmitosis 5y ago
    Sure, if the first thing is callable, you always go with the default eval strategy, like in this case: (map - (quote (1 2 3))) I'm only talking about cases where the first thing isn't callable, but the second thing is: (3 + 1) It seems like this couldn't ever be a problem, because the only cases in which the infix strategy would be used are cases which would have been invalid programs anyway. Does that make sense?
Jach 5y ago
You don't have to give up on anything, that's the beauty of Lisp. Here's a library from 1993: https://github.com/quil-lang/cmu-infix https://github.com/quil-lang/cmu-infix Though personally I don't particularly find (+ 1 2 3 4 5) less readable than 1+2+3+4+5, and since most of my programs don't have math expressions much more complicated than that, even without cmu-infix or alternatives (Maxima is great when you need to do real math, and for other related things I might as well link https://github.com/CodyReichert/awesome-cl#numerical-and-scientific https://github.com/CodyReichert/awesome-cl#numerical-and-sci...) I'd find the rest of the tradeoffs worth it, much like once I thought despite Python not having i++ or ++i it was still worthwhile. (In Lisp, by the way, one would use (incf i).)
Blikkentrekker 5y ago
> There's a reason people like syntax, because it is expressive. There are also many people who like the imperial system more than the metric system. Given that new languages with such syntax continue to be developed and that many express that they favor it, it is at best a personal taste, and at worst simply inertia. “conventional mathematical notation” was never designed; much like the imperial system, it organically grew and I find it somewhat arbitrary what operations receive an infix operation and what do not and it even depends on the language in some cases. That being said, I really do not favor `string-append` where `strapp` suffice. I especially do not favor `call-with-current-continuation` over `call/cc`.
geocar 5y ago
> Well, also give up infix functions/operators, False. All you really need is a bijection: McCarthy himself suggested f[x;y]<=>(f x y) and it seems reasonable (and it turns out to be actually useful!) to declare a domain of f where you permit xfy<=>(f x y) One of his students implemented this: http://i.stanford.edu/pub/cstr/reports/cs/tr/68/92/CS-TR-68-92.pdf http://i.stanford.edu/pub/cstr/reports/cs/tr/68/92/CS-TR-68-... which certainly has... other issues, but I don't agree infix syntax is incompatible with lisp. > operator precedence, readable equations, etc. Yes please. "readability" is usually given to mean "most people believe they can read it" and not something useful like "most people understand it fully", and nearly any reduction in typing that operator-precedence can offer can be obtained with a simpler rule (like right-of-left) and ordering. That is to say these things (in their usual meaning) have net-negative value to programs and programmers, are a frequent root-cause of bugs.

pjmlp 5y ago

Same here, never got why it should be such a big deal.