Python syntax in Lisp and Scheme

Andrew Dalke adalke at mindspring.com
Sat Oct 11 19:33:43 EDT 2003


Me:
> > My continued response is that [Lisp is] not optimal for all
> > domains.

Pascal Costanza:
> Yes, we disagree in this regard.

*Shrug*  The existence of awk/perl (great for 1-liners on the
unix command-line) or PHP (for simple web programming) or
Mathematica (for symbolic math) is strong enough evidence for
me to continue to disagree.

Pascal Costanza:
> However, you have mentioned that someone has implemented an quantum
> extension for Perl - and if that's possible then you can safely bet that
> it's also possible in pure Lisp.

The fact that all computing can be programmed in Turing Machine
Language doesn't mean TML is the optimal programming language.

The fact that there is perl code for emulating *some* quantum
programming means that Lisp can handle that subset.  It doesn't mean
that people have fully explored even in Lisp what it means to do all
of quantum computing.

> Furthermore, it has been suggested more than once that a valid
> working model is that a good Lisp programmer can provide a
> domain-specific language for the non-professional programmer. It's very
> likely that a DSL matches better the needs of the user than some
> restricted general-purpose language.

Another *shrug*  And a good C programmer can provide a
domain-specific language for the non-professional programmer.

Any good Python programmer could make an implementation
of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like

import lisp
def spam(distance):
    """(time_to_fall 9.8 distance)"""
spam = lisp.convert(spam)

def time_to_fall(g, distance):
  print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"

print spam(10)

> Ah, but then you need to constantly change the syntax and need to
> remember the idiosyncrasies of several languages.

Yup.  Just like remembering what macros do for different domains.
I firmly believe people can in general easily handle much more
complicated syntax than Lisp has.  There's plenty of room to
spare in people's heads for this subject.

> I am not so sure whether this is a good idea. Personally, I prefer not
> to think about syntax anymore. It's boring. But that's maybe just me.

wave equation vs. matrix approach
Newtownian mechanics or Lagrangian
measure theory or non-standard analysis
recursive algorithms vs. iterative ones
travelling salesman vs. maximum clique detection

Each is a pair of different but equivalent ways of viewing the same
problem.  Is the difference just syntax?

> > Ahh, but that assumes that behaviour is the only important thing
> > in a language.
>
> No.

Thank you for your elaboration.  You say the driving force is the
ability to handle unexpected events.  I assumed that means you need
new styles of behaviour.

> If it's only a syntactical issue, then it's a safe bet that you can add
> that to the language. Syntax is boring.

Umm... Sure.  C++ can be expressed as a parse tree, and that
parse tree converted to an s-exp, which can be claimed to be
a Lisp; perhaps with the right set of macros.

Still doesn't answer my question on how nicely Lisp handles
the 'unexpected' need of allocating objects from different
memory arenas.

> Sounds like a possible application for the CLOS MOP.

Or any other language's MOP.

> Seriously, I haven't invented this analogy, I have just tried to answer
> a rhetorical question by Alex in a non-obvious way. Basically, I think
> the analogy is flawed.

Then the right solution is to claim the analogy is wrong, not
go along with it as you did.  ;)

                    Andrew
                    dalke at dalkescientific.com






More information about the Python-list mailing list