Python syntax in Lisp and Scheme

[Alex Martelli]

On Friday 10 October 2003 05:52 am, Daniel Berlin wrote:
> On Oct 9, 2003, at 5:33 PM, Alex Martelli wrote:
> > Rainer Deyke wrote:
> >> Pascal Costanza wrote:
> >>> Pick the one Common Lisp implementation that provides the stuff you
> >>> need. If no Common Lisp implementation provides all the stuff you
> >>> need, write your own libraries or pick a different language. It's as
> >>> simple as that.
> >>
> >> Coming from a C/C++ background, I'm surprised by this attitude.  Is
> >> portability of code across different language implementations not a
> >> priority for LISP programmers?
> >
> > Libraries distributed as binaries are not portable across different C++
> > implementations on the same machine (as a rule).
>
> This isn't true anymore (IE for newer compilers).

Wow, that IS great news!  Does it apply to 32-bit Intel-oid machines (the
most widespread architecture) and the newest releases of MS VC++ (7.1)
and gcc, the most widespread compilers for it?  I can't find any docs on what 
switches or whatever I should give the two compilers to get seamless interop.

Specifically, the standard Python on Windows has long been built with MSVC++
and this has given problems to C-coded extension writers who don't own that
product -- it IS possible to use other compilers to build the extensions, but 
only with much pain and some limitations (e.g on FILE* arguments).  If this
has now gone away there would be much rejoicing -- with proper docs on the
Python side of things and/or use of whatever switches are needed to enable
this, if any, when we do the standard Python build on Windows.


> Mangling, exception handling, etc, is all covered by the ABI.
>
> IBM's XLC 6.0 for OSX also follows this C++ ABI, and is thus compatible
> with G++ 3.x on OSX.

I'm not very familiar with Python on the Mac but I think it uses another
commercial compiler (perhaps Metrowerks?), so I suspect the same question
may apply here.  It's not as crucial on other architectures where Python is
more normally built with free compilers, but it sure WOULD still be nice to
think of possible use of costly commercial compilers with hypothetically
great optimizations for the distribution of some "hotspot" object files, if 
that sped the interpreter up without giving any interoperability problems.


Alex