Re: Very poor Lisp performance

Ulrich Hobelmann wrote:
> Jon Harrop wrote:
>> Joe Marshall wrote:
>>> Infix macros are *hard*.
>>
>> Do you mean it is difficult to implement infix in Lisp?
>
> No, others mentioned that *there are* infix parsers (reader macros) for
> Lisp. Most people don't use them I guess :D

Then why are they "hard"? Perhaps I misunderstood Joe. I thought he meant it
was difficult to implement infix operators in Lisp. Now I'm thinking maybe
he meant it is easy to implement infix operators but it is then difficult
to write macros that use infix syntax?

Presumably that is a Lisp-specific problem because Mathematica has no
problem using infix notation...

>>> You need to learn the prefix notation *anyway* (because code that
>>> operates on code needs to operate at the abstract syntax level,
>>> which in lisp is naturally prefix-notated lists).
>>
>> So Lisp is rather tied to the built-in prefix notation.
>
> Not at all. Implement whatever syntax you want. If you don't like Lisp
> syntax at all use a complete, different syntax (and language) like Dylan.

So you disagree with Joe saying that "lisp is naturally prefix-notated
lists". You believe that prefix/infix/postfix makes no difference in Lisp?

>>> (consider the popularity of ternary ? : operator).
>
> It's not exactly elegant IMHO. I MUCH prefer Lisp's style of everything
> being an expression, so I can simply say (if (test bla) foo bar)
> *everywhere* I want, unlike C, which makes that stupid if-else/?:
> distinction (and both look ugly, and if-else requires ();{}s all over
> the place).

Yes, everything being an expression is definitely better.

>> Do you think that syntax is a significant source of errors when
>> programming? I believe that my errors tend to be at higher levels, e.g.
>> algorithms.
>
> True, an experienced C coder probably doesn't make syntax mistakes, or
> just ()s the code to be sure. But I feel like in a straight-jacket when
> coding C. Not because of memory management, but because of syntax (like
> the inability to use if and switch as an expression, the need to create
> a named function in order to pass it as a parameter, the awkward syntax
> for creating structures that I want to pass as arguments...).

Yes. To be fair, you are trying to do functional programming in an
imperative language. Most people do the converse, trying to do imperative
programming in a functional language. :-)

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
.

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: Any macro for inserting math "normally"
    ... in Lisp. ... syntax are both that it simplifies out the need to write gratuitous ... infix syntax, but it's also not something where I think the two ... I see no reason it couldn't be a hard requirement that both syntaxes ...
    (comp.lang.lisp)
  • 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)
  • Re: Very poor Lisp performance
    ... was difficult to implement infix operators in Lisp. ... Now I'm thinking maybe he meant it is easy to implement infix operators but it is then difficult to write macros that use infix syntax? ...
    (comp.lang.lisp)
  • Re: Python syntax in Lisp and Scheme
    ... Python people should not pick fights with Lisp people. ... Lisp people should not insult Alex Martelli. ... Python's syntax is one of the worst features of the language and ... Joe Marshall's analysis is establishes this. ...
    (comp.lang.python)