Python syntax in Lisp and Scheme

[Pascal Costanza]

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
> 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.

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
>>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")?

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
>>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."

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
>>before.
> 
> 
> Ahh, but that assumes that behaviour is the only important thing
> in a language.

No.

> 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 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
>>tasks.)
> 
> 
> 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 
on them.

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.


Pascal