Arc Forumnew | comments | leaders | submitlogin
2 points by kennytilton 6114 days ago | link | parent

Yeah, I saw that about the foo getting italicized. I guess I'll use octothorpes for asterisks from now one. :)

The coolest hackery has beautiful mathematical gems at the core or in the cleverest bits.

I guess I am not emitting the coolest hackery. :) I know I never put math formulas in my code because it is such a PITA when I do. :) I thought about challenging math infix proponents to post one or two examples from their code, no cheating and contest closed to scientists and engineers.

I do not see it as religious, just a simple question: how often does this come up? And I tried to make another point: this is a Lisp with an intelligible macro mechanism, do what at least one CL project did: write an infix-eating macro! Then you do not need whitespace either, you can have any syntax you want inside the macro. If the task sounds daunting, well that is why I suggested asking on c.l.lisp for the recommended infix package -- just port it to Arc.



2 points by cadaver 6114 days ago | link

There are two concepts under discussion:

First, disallowing arithmetic operators in symbol names, so that (a+b/c) is interpreted like (a + b / c). All the replies to that, up till now, can be summed up like this:

  eds: *I don't really think it is worth it*
  kennytilton: *impoverishing the Arc naming syntax*
  cadaver: *seems not such a good idea after all*
Secondly, whether or not to have some language support for infix. As can be seen in previous discussion, with eds's system, you only need swapped positions where a literal-in-functional-position is encountered for infix support. Paul Graham said that literals in functional position are valuable real estate, nevertheless a comment regarding such an idea can be found in the arc1 source.

One good point of having support is brevity for math-infix users. The only bad point that I see is that we use up the valuable number-in-functional-position real estate, which could have been used for something else.

Supporting infix may not only be good for math. Consider the following:

  (sort (fn (sm gr) (sm < gr)) somelist)
I'm sorry that I can't supply any good examples of heavy maths in real world programs, though I don't doubt that such exist (ciphers?). On the other side, if in a program there isn't any heavy use of maths at all, except for a single mathematical formula that the programmer would like to write in infix, then using a separate macro package would introduce a dependency, and that might make the programmer grudgingly write out the formula in prefix. Another good case for lisp-infix is that when, like me, you tend to copy other's non-lisp formulae then, in eds's infix system, it would look more like its original form.

-----

2 points by kennytilton 6114 days ago | link

Supporting infix may not only be good for math. Consider the following: (sort (fn (sm gr) (sm < gr)) somelist)

Consider: (sort < somelist)

And if (sort (fn (x y) (< x y)) somelist) looks awkward then maybe the issue is prefix altogether? I think anyone trying Arc who is new to Lisp might try Just Lisping (in Arc, of course) for a few weeks before even thinking about changing the language. These things take time and until one has done enough coding to get fluent (or throw up ones hands and say it has been three weeks and I still hate this!) one cannot even form an opinion about the whatever that thing might be. It is like an editor or IDE -- I hated the IDE I love now but made myself wait a month before ripping the vendor a new one. Now people accuse me of being on their sales team.

Case in point: Arc. It is hard judging the brevity/parens stuff because I am in pain anyway without a decent IDE, without a debugger, without a standard library... but I slogged my way thru a port of Cells from Lisp to Arc and some of the brevity is growing on me (I deliberately stopped doing a transliteration and reinvented over the keyboard so I could feel the language better) and at this point I think I can say I would not kick Arc out of bed. Something like that.

btw, if we are just talking about one math formula in a blue moon, why bother? I mean, it would be fun if it had no cost, sure, but apparently pg has plans for numbers in the functional position. Anyway...

-----

2 points by cadaver 6114 days ago | link

cadaver wrote:

  (sort (fn (sm gr) (sm < gr)) somelist)
Yes, a stupid example, sorry.

What are those plans for numbers in the functional position? pg's comments in the arc1 source are completely compatible with eds's system:

Comment 1 is about literal numbers as functions: (1) evaluates to 1

But that is not incompatible with comment two, which is about swapping first and second positions: (1 + 1) evaluates to 2

In fact, math-infix can only benefit if both were added to the language.

-----

1 point by eds 6114 days ago | link

Although literals in functional position may be valuable real estate, I think that infix math is valuable enough to justify using it (at least until we think of something more important).

The only other thing that was suggested in the comment in ar-apply was that literals in functional position might be constant functions. I think infix syntax gives the programmer far more expressive power than being able to denote constant functions.

-----