Popular conceit about learning programming languages

[Pascal Costanza]

Alex Martelli wrote:
> Pascal Costanza wrote:
>    ...
> 
>>>>Er, I have thought that's exactly the point. What do you need a
>>>>backstage language for that is less powerful than the frontstage
>>>>language?
>>>
>    ...
> 
>>Languages like C and assembler are more powerful than, say, Python
>>because they allow you to circumvent type restrictions and fiddle with
>>the operating system level.
[...]

> Having the whole
> VM be in CL seems a different, separate project, with benefits
> and costs different from the "CL for extensions" project -- e.g.
> among the benefits the ability to use any CL implementation rather
> than being tied to one or a few that supply the FFI you want,
> among the costs the need to recode all the currently-C-coded Python 
> standard library modules which, in a "CL for extensions" setting, 
> you could simply reuse without any effort.
> 
> 
> 
>>So my mental model is as follows: Scripting languages allow you to
>>solve, say, 90% of the problems in straightforward and simple ways.
>>However, some problems are complicated or demanding enough that you (or
>>"someone";) needs to revert to the more powerful backstage language.
> 
> 
> I think this model lacks the key features of speed and code reuse.
> 
> 
>>I don't see how Java can play this role for Python because Java neither
>>allows you to fiddle with the machine level nor allows for writing
>>complicated algorithms, at least not when compared to Python.
[...]

>>Or is there something I miss?
> 
> 
> I think so and I've tried to show why.
[...]

You have given very useful comments, and I think they help to sort some 
things out.

So what I have in mind is not only a way to make use of Common Lisp 
libraries from Python. I am pretty sure that this is already possible. I 
rather think that implementing Python in Common Lisp has several 
advantages beyond mere reuse options. Here are some ideas.

* Common Lisp provides the notion of method combinations. In LisPython 
it would be possible to use these method combinations for method written 
in Python. Here is something I can already do in my CL-based JVM 
implementation.

(define-java-method m :before (...)
   (...))

This defines code that gets executed before each invocation of the 
method m. (You can also have :after and :around methods. It's not 
exactly as illustrated, but it's close.)

So we could, for example, also have.

(define-python-method m :after (...)
   (...))

You could also define your own method combinations. (There's not enough 
space here to explain the whole concept of method combinations.) For 
example, this allows you to implement your own orthogonal persistence 
layer without the need to change existing Java/Python classes. (Ah, yes, 
and there's also the MOP... ;)

* Common Lisp has a sophisticated exception handling mechanism that 
allows you to tweak the stack and environment and then try to restart 
the code that has caused the exception. For example, this can be useful 
for long-running code. (Imagine your code has been doing some 
calculations during the last few days and throws an exception. You would 
be happy if you wouldn't need to restart the whole calculation again, 
but only the portion that caused the exception.)

...and there are some other powerful Common Lisp features that could be 
useful for Python. Even if you would only use such a LisPython during 
development it would provide some benefits because of the nice and 
powerful Common Lisp IDEs.


Pascal

-- 
Pascal Costanza               University of Bonn
mailto:costanza at web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)