Python syntax in Lisp and Scheme
costanza at web.de
Sun Oct 12 00:30:30 CEST 2003
Andrew Dalke wrote:
> 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
> 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
Yes, we disagree in this regard.
> (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.)
I am no expert in quantum computing, so I can't comment on that.
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.
> > 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
> 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")?
I believe that non-professional are more capable than most of us seems
to think. 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.
>>Pythonistas are probably driven by the assumption that the language
>>designers have found the best language feature for any task that might
> 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."
Ah, but then you need to constantly change the syntax and need to
remember the idiosyncrasies of several languages.
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.
>>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
> 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
> 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 don't know. I have to ask my vendor. ;-)
> 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.
If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
> (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.)
Sounds like a possible application for the CLOS MOP.
> > This makes them feel safe. (And the large libraries provided
>>with Common Lisp and some Scheme systems still cover 90% of the standard
> Except for my standard tasks in bioinformatics and chemical
> informatics. ;)
Again, I don't know. You don't really expect me to know everything about
any conceivable field of computer science, do you? ;)
>>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.
You have forgotten the stupid politicians who go to war because it makes
them look better on television. No, I don't feel comfortable to depend
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.
More information about the Python-list