Python syntax in Lisp and Scheme

[Daniel Berlin]

On Oct 10, 2003, at 5:12 AM, Alex Martelli wrote:

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

Yes, but not windows.


>  and the newest releases of MS VC++ (7.1)
> and gcc, the most widespread compilers for it?

GCC, yes.

MS is not participating in the ABI (take that to mean what you will), 
AFAIK.

http://codesourcery.com/cxx-abi
(it's not really draft anymore since compilers are shipping using it, 
but it is updated for bug fixes occasionally)

"This document was developed jointly by an informal industry coalition 
consisting of (in alphabetical order) CodeSourcery, Compaq, EDG, HP, 
Intel, Red Hat, IBM and SGI. Additional contributions were provided by 
a variety of individuals."


>  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 depends. I've built it with both.
>  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.
>

At least on Mac, Apple's gcc -fast is better than any other compiler 
around, according to recent benchmarks.

Unsurprising to me, but i'm a gcc hacker, so i might be biased a bit. :P

Most, if not all, optimizations that commercial compilers implement are 
or are being implemented in gcc for 3.5/3.6.

--Dan