Python syntax in Lisp and Scheme

[Andrew Dalke]

Pascal Costanza:
> To put it in a provocative
> way, Python is a domain-specific language for vaguely defined domains -
> those that GvR (subconsciously?) had in mind when he designed the
language.

But by the same vein, is not Lisp is a domain-specific language for
vaguely defined domains?  You say that's because Lisp can be used
for all domains.  My continued response is that it's not optimal for all
domains.  (Also, in another post I conjectured that a thoeretical
quantum computing 'Lisp' may have features for manipulating ensembles
of structures, in ways inappropriate to current Lisps.)

 > But on the other hand, it is also clear that for unknown domains yet to
> be explored you cannot know the best set of features in advance _by
> definition_.

I'll agree with that.  So why should Lisp, designed in the 1950s,
provide the best set of features (and I include more than semantic
abilities) for situations unenvisioned half a centry later (eg, the concept
of a "non-professional programmer")?

> Pythonistas are probably driven by the assumption that the language
> designers have found the best language feature for any task that might
> arise.

Not at all.  When I need language features best found in C (using
shared memory, or memory mapped I/O), I use C; perhaps called
from Python.

Were I to need logic programming, I would use at least consider
Prolog, with bindings like AmziPy or PyProlog, or cousins like
the Python/CLIPS interface.

(Most of the time though, I need libraries.  Eg, calling out to a
Fortran binary, using 'web services', CORBA, or even, when
I need browser applet features best found in Java,  I use Python
in its Jython incarnation.)

The phrase I'm trying to push is "multiple language paradigm;
not multiple paradigm language."

> Lispniks are driven by the assumption that there is always the
> unexpected. No matter what happens, it's a safe bet that you can make
> Lisp behave the way you want it to behave, even in the unlikely event
> that something happens that no language designer has ever thought of
> before.

Ahh, but that assumes that behaviour is the only important thing
in a language.  I disagree with that assumption, and that difference
in belief is one of the core reasons this thread has gone on so long.

> And even if you cannot find a perfect solution in some cases,
> you will at least be able to find a good approximation for hard
> problems.

So, umm, how does Lisp handle shared memory?  Can I, as
with C++, say that certain objects/data structures are to be
allocated from a block of shared memory rather than the standard
memory arena?  What's the way to do I/O through a
memory-mapped port as on an old DOS machine?

Python cannot do the first, excepted in limited cases using
extensions written in C/C++, which is also how to handle
the second case.

I'm not saying that Lisp doesn't handle support for allocation
from multiple arenas; my searches showed many examples
of using Lisp on shared memory parallel machines.  However,
given my understanding of the language, it isn't obvious how
that's done.  By comparison, C++ has syntax support for
letting an class define the allocator for an instance and its
standard templates also take an optional memory allocator.

(Background on when I used C++'s per-class allocators.  I
was writing software for the CAVE, an immersive virtual
reality system.  Each wall of the CAVE is driven by a
different CPU.  The main software driving the visualization
runs on yet another CPU, and uses high-speed shared
memory to update the model viewed by the display CPUs.
It was easy to support; I made a new subclass for the
model data structures, with an allocator which used the
shared memory arena.  I then made a new container (this
was pre STL) for storing those objects.  A few library
calls and it was working.)

 > This makes them feel safe. (And the large libraries provided
> with Common Lisp and some Scheme systems still cover 90% of the standard
> tasks.)

Except for my standard tasks in bioinformatics and chemical
informatics.  ;)

> > The worst case for productivity is probably when two _perfectly
> > equivalent_ ways exist.  Buridan's ass notoriously starved to death in
> > just such a worst-case situation; groups of programmers may not go
> > quite as far, but are sure to waste lots of time & energy deciding.
>
> No, the worst case for productivity is when no way exists.

When there are two perfectly equivalent ways to do something,
people may be stuck in "analysis lock" trying to figure out which
one to take.  When there's no way to do something the answer is
to make a way -- which may be to use Lisp.

Here's a page on Buridan's ass
http://www.postmodernvillage.com/eastwest/issue5/ftf05.html
] The theory often referred to as "Buridan's ass" states that, when
] given the option of two equally wonderful piles of hay, the ass
] will starve to death because it cannot choose. This concept was
] first discussed in writing by Aristotle, but has been in existence
] long before it was documented in writing

Stretching the analogy, if there was no solution (no hay), the ass
would keep on looking for food.

> Yes, it is good thing that a language enables you to "define bombs
> waiting to go off", because this means that you can also define
> solutions for your unexpected problems.

Ahh, more analogies.  Most people don't work in munitions
factories.  While some are able to make their own bombs,
most are happy to relegate the task to professionals, and
depend on still others (the military) to deploy those bombs.

                    Andrew
                    dalke at dalkescientific.com