Re: Any macro for inserting math "normally"

"Juan R." <juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx> writes:

On Apr 21, 11:47 pm, Kent M Pitman <pit...@xxxxxxxxxxx> wrote:

It's a recurring theme, the wanting of infix
in Lisp.

For instance, for the 'next' LISP (Arc), Graham want infix math, but
it looks like a macro approach.

Do you wait some future infix-LISP to success in a way prefix-LISP
could not during decades?

I'm not anxious for it personally. My reasons for why I like Lisp
syntax are both that it simplifies out the need to write gratuitous
parsers and, importantly and less seldom mentioned, it allows for a
simplified editing model that allows me to do from the keyboard in
Emacs things that are hard to do from either the keyboard or even the
mouse in other languages--lifting or reordering bounded fragments of
code reliably. There's a more detailed example of this in my Slashdot
interview in Part 1 of my Slashdot interview from a few years back at:

http://developers.slashdot.org/article.pl?sid=01/11/03/1726251

It's not personally desirable to me to change the availability of
infix syntax, but it's also not something where I think the two
are incompatible.

MACSYMA, a language for symbolic algebra, was basically an extension
of Lisp, and it had a parser that allowed you to code extensions in
either Lisp or Macsyma. Dylan had it, too. I think in both cases,
the correspondence was given up for political, not technical reasons.
I see no reason it couldn't be a hard requirement that both syntaxes
work. I see no reason it couldn't be that Lispy syntax would win if
some unexpected need to press on into other areas were come across.
I've seen it done well enough that I believe the contest is artificial.

Dylan had a similar choice to make, but it gave up Lispy syntax, as
far as I can tell, in a deliberate attempt to distance itself from
Lisp, not because a technical solution to keeping the two in sync was
attempted and utterly failed. Where there is a failure of will, it's
generally easy to find a failure of imagination.

So while I'm not anxious for an infix alternative, I would welcome it
only as a confirmation of my belief that the two could sit side by
side without injury.

I've been recently reading Ayn Rand's book The Fountainhead (a book I
strongly recommend, by the way, along with her Atlas Shrugged, which I
also found quite interesting). The Fountainhead makes many
interesting points, but one that it seems to repeat implicitly
throughout is how easy it is for people to just believe the
sometimes-ridiculous claims of others, based solely on the comfort of
numbers of people who have chosen to believe it, and really without
doing an independent analysis, based on fact, of what is, in fact,
possible or true. I mention the book because I think this particular
syntax issue is driven largely by pack mentality, with very little
attention to facts, just as happens for "architectural features" in
the book.

Summing up: Is infix desired by me? No. Is it by some? Yes. Has it
been tried? Yes. Is it something that is technicall workable? It has
seemed so. Have systems that used it survived? No. Was that the
reason of their demise? Probably not. Would it hurt to add it as an
option? I doubt it. Does it require help from the language
designers? Probably not.

What's holding it back, then? My guess: Lack of will on the part of
the people who want it, and frittering away their energy on
complaining to people who don't want it that it should be offered by
those who don't want it, rather than just implementing it themselves.
Some people would say that is, itself, an objective test of whether
people are really interested. True interest can often be measured by
someone putting resources on the line to make it happen. It's easy to
just _say_ "I'm interested", but when push comes to shove, many
statements of interest fall away.

In my opinion, people who think language syntax is what stands in the
way of them and commercial success are kidding themselves. If you're
not going to build something interesting, why does the syntax matter?
If you are going to build something interesting, why does the syntax
matter?
.

Relevant Pages

  • Re: Very poor Lisp performance
    ... >>> Do you mean it is difficult to implement infix in Lisp? ... > to write macros that use infix syntax? ... your language is infix it's harder to write macros because the macros ...
    (comp.lang.lisp)
  • Re: Very poor Lisp performance
    ... >> Do you mean it is difficult to implement infix in Lisp? ... Perhaps I misunderstood Joe. ... >>> operates on code needs to operate at the abstract syntax level, ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... The claim _seems_ to be that the Lisp code was better than the SPUC ... This goes back to the syntax in Lisp. ... languages however: one is that a real language provides reasonably ... reason that this is often helpful in solving the problems for which it ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... The claim _seems_ to be that the Lisp code was better than the SPUC ... This goes back to the syntax in Lisp. ... languages however: one is that a real language provides reasonably ... reason that this is often helpful in solving the problems for which it ...
    (comp.lang.cpp)
  • Re: What about these?
    ... It is thus not a infix operator. ... i already explained difference between operators at S-expr syntax ... 'invisible comma operator'. ... McCarthy syntax for LISP. ...
    (comp.lang.lisp)