Shed Skin的第一个版本，Python-to-C ++编译器。 [英] First release of Shed Skin, a Python-to-C++ compiler.
问题描述
经过九个月的努力，我很自豪地将我的宝贝介绍给
世界：一个实验性的Python-to-C ++编译器。它可以将许多
Python程序转换为优化的C ++代码，无需任何用户干预
，例如添加类型声明。它使用相当先进的静态类型
推理技术来自行推断类型信息。在
中，它确定推导出的类型是否可以参数化，
如果是这样，它会生成相应的C ++泛型。根据推导出的
类型信息，它还会尝试将堆分配转换为
堆栈和静态预分配（如果这是
，则回退到libgc失败了。）
编译器的动机是，在许多情况下，它应该可以自动推导C ++版本的Python程序，
使用户能够享受Python的生产力和C ++的
效率。它最适合用相对静态的C ++风格编写的Python程序，实质上使用户可以在更高级别指定C ++
程序。
目前编译器正确处理124个单元测试，其中6个是
，这是100到200行的严肃程序：
-an othello玩家
-两个可满足求解器
-a日本拼图解算器
-a sudoku solver
- 一个神经网络模拟器
不幸的是我只是一个人，还有很多工作要做完b / b
。目前，编译器接受的Python程序类型有几个限制。即便如此，在很多情况下，还有足够的余额可以保持高效率。
但是，对于大多数大型程序，可能还有一些不足之处/>
首先需要修复的问题和一些外部依赖关系
用C ++实现/桥接。
这个初始版本，我希望吸引其他人来帮助我。
找到剩下的问题，帮助实现外部依赖，最后希望
甚至可以为编译器本身做出贡献。我很高兴收到编译器做的小程序或者应该能够处理的小程序。如果你是一个C ++模板向导，并且你有兴趣使用内置的
类型的C ++实现，我也很乐意与你联系。实际上，我会想要和任何对编译器稍微感兴趣的人交谈，因为这对我来说非常激励。
源代码可在以下站点获得。有关简单的安装/使用说明，请查看
自述文件。让我知道你是否想要创建ebuild / debian软件包。
Sourceforge网站： http://shedskin.sourceforge.net
Shed Skin博客： http://shed-skin.blogspot.com
如果您回复此邮件，请直接回复我。谢谢！
积分
部分编译器由Google赞助，通过其Summer of
代码程序。我非常感谢他们在困难时期让我保持积极的动力
。我也很感谢Python软件
基金会为夏天的代码选择了我的项目。最后，我要感谢我的大学顾问Koen Langendoen为这个项目指导
。
详情
下面将详细介绍
编译器的各个方面。在认真使用编译器之前，请确保
特别了解它的局限性。
主要特点
- 非常精确，高效的静态类型推断（迭代对象
轮廓分裂，每次迭代执行笛卡尔积的算法
算法）
-stack and static预分配（libgc用作后备）
-支持列表推导，元组赋值，匿名函数
- 生成任意复杂的类和函数模板
（甚至成员模板，或通用的，嵌套的列表推导）
-二元元组在内部进行分析
-对继承的理解（例如list（ dict / list）成为
list< pyiter< A>>）
-分层项目支持：生成相应的C ++
层次结构，包括（嵌套）Makefile; C ++命名空间
-带有推导类型的源代码注释
-builtin类，函数（枚举，总和，最小值，最大值，范围，zip ...）
-polymorphic内联缓存或虚拟变量/调用（未经过充分测试）
-always unbox scalars（如果标量是
与指针混合，则编译器会出错）类型）
-full源代码在麻省理工学院许可下可用
主要限制/ TODO'
-Windows支持（我没有Windows，对不起）
-reflection（getattr，hasattr），动态继承，eval，..
-mixing scalars with pointer类型（例如单个变量中的int和None）
- 在单个容器实例变量中混合不相关的类型其他
比元组-2
- 持有长度> 2的元组中不同类型的对象;
内置''zip''只能带2个参数。
-exceptions，generator，嵌套函数，运算符overloadi ng
-recursive类型（例如a = []; a.append（a））
-将浮动和整体混合在一起时出现一些问题
-varargs（* x）得不到很好的支持;不支持关键字args
-arbitrary-size arithmetic
-possible non-termination（'''recursive customization''，还没有
遇到它还需要
-profiling才能扩展到非常大的程序
-将二进制类型元组与单类型元组组合在一起（例如（1,1.0）+（ 2，））
- 小元组的盒装（应该形成一个很好的加速）
-foreign代码必须用C ++建模和实现/桥接
-some builtins尚未实现，例如''reduce''和''map''
After nine months of hard work, I am proud to introduce my baby to the
world: an experimental Python-to-C++ compiler. It can convert many
Python programs into optimized C++ code, without any user intervention
such as adding type declarations. It uses rather advanced static type
inference techniques to deduce type information by itself. In
addition, it determines whether deduced types may be parameterized,
and if so, it generates corresponding C++ generics. Based on deduced
type information, it also attempts to convert heap allocation into
stack and static preallocation (falling back to libgc in case this
fails.)
The compiler was motivated by the belief that in many cases it should
be possible to automatically deduce C++ versions of Python programs,
enabling users to enjoy both the productivity of Python and the
efficiency of C++. It works best for Python programs written in a
relatively static C++-style, in essence enabling users to specify C++
programs at a higher level.
At the moment the compiler correctly handles 124 unit tests, six of
which are serious programs of between 100 and 200 lines:
-an othello player
-two satisfiability solvers
-a japanese puzzle solver
-a sudoku solver
-a neural network simulator
Unfortunately I am just a single person, and much work remains to be
done. At the moment, there are several limitations to the type of
Python programs that the compiler accepts. Even so, there is enough of
Python left to be able to remain highly productive in many cases.
However, for most larger programs, there are probably some minor
problems that need to be fixed first, and some external dependencies
to be implemented/bridged in C++.
With this initial release, I hope to attract other people to help me
locate remaining problems, help implement external dependencies, and
in the end hopefully even to contribute to the compiler itself. I
would be very happy to receive small programs that the compiler does
or should be able to handle. If you are a C++ template wizard, and you
would be interested in working on the C++ implementation of builtin
types, I would also love to get in contact with you. Actually, I''d
like to talk to anyone even slightly interested in the compiler, as
this would be highly motivating to me.
The source code is available at the following site. Please check the
README for simple installation/usage instructions. Let me know if you
would like to create ebuild/debian packages.
Sourceforge site: http://shedskin.sourceforge.net
Shed Skin blog: http://shed-skin.blogspot.com
Should you reply to this mail, please also reply to me directly. Thanks!
Credits
Parts of the compiler have been sponsored by Google, via its Summer of
Code program. I am very grateful to them for keeping me motivated
during a difficult period. I am also grateful to the Python Software
Foundation for chosing my project for the Summer of Code. Finally, I
would like to thank my university advisor Koen Langendoen for guiding
this project.
Details
The following describes in a bit more detail various aspects of the
compiler. Before seriously using the compiler, please make sure to
understand especially its limitations.
Main Features
-very precise, efficient static type inference (iterative object
contour splitting, where each iteration performs the cartesian product
algorithm)
-stack and static pre-allocation (libgc is used as a fall-back)
-support for list comprehensions, tuple assignments, anonymous funcs
-generation of arbitrarily complex class and function templates
(even member templates, or generic, nested list comprehensions)
-binary tuples are internally analyzed
-some understanding of inheritance (e.g. list(dict/list) becomes
list<pyiter<A>>)
-hierarchical project support: generation of corresponding C++
hierarchy, including (nested) Makefiles; C++ namespaces
-annotation of source code with deduced types
-builtin classes, functions (enumerate, sum, min, max, range, zip..)
-polymorphic inline caches or virtual vars/calls (not well tested)
-always unbox scalars (compiler bails out with error if scalars are
mixed with pointer types)
-full source code available under the MIT license
Main Limitations/TODO''s
-Windows support (I don''t have Windows, sorry)
-reflection (getattr, hasattr), dynamic inheritance, eval, ..
-mixing scalars with pointer types (e.g. int and None in a single variable)
-mixing unrelated types in single container instance variable other
than tuple-2
-holding different types of objects in tuples with length >2;
builtin ''zip'' can only take 2 arguments.
-exceptions, generators, nested functions, operator overloading
-recursive types (e.g. a = []; a.append(a))
-expect some problems when mixing floats and ints together
-varargs (*x) are not very well supported; keyword args are not supportedyet
-arbitrary-size arithmetic
-possible non-termination (''recursive customization'', have not
encountered it yet)
-profiling will be required for scaling to very large programs
-combining binary-type tuples with single-type tuples (e.g. (1,1.0)+(2,))
-unboxing of small tuples (should form a nice speedup)
-foreign code has to be modeled and implemented/bridged in C++
-some builtins are not implemented yet, e.g. ''reduce'' and ''map''
推荐答案
Mark Dufour< ma ********* @ gmail.com> ;写道：
Mark Dufour <ma*********@gmail.com> writes:
经过九个月的努力，我很自豪地将我的宝贝介绍给
世界：一个实验性的Python-to-C ++编译器。
After nine months of hard work, I am proud to introduce my baby to the
world: an experimental Python-to-C++ compiler.
哇，看起来很酷。但为什么而不是Pypy？
Wow, looks really cool. But why that instead of Pypy?
嗨！
adDoc'的网络工作者Phil写道：
Hi!
adDoc''s networker Phil wrote:
实验性的Python-to-C ++编译器。
为什么而不是Pypy？
。 pypy编译成llvm（低级虚拟机）字节码
这显然不如来自c ++编译器的本机代码快;
experimental Python-to-C++ compiler.
why that instead of Pypy?
. pypy compiles to llvm (low-level virtual machine) bytecode
which is obviously not as fast as the native code coming from c++ compilers;
PyPy目前可以将Python代码编译为C代码和LLVM字节码。
请注意，即使对于LLVM字节码，该参数也是无效的，因为LLVM
（尽管它的名称，这可能导致人们思考它是类似Java的）
将其字节码编译为本机汇编程序。
但是pypy的主要任务
只是有一个python系统是
它真的只是简单的python（它完全在CPython之上运行
毕竟）以及一些限制 - 这看起来类似于棚屋强加的
限制。
。没有理由为什么pypy项目不能有.NET架构而不是类似Java的安排我认为现在已经有了
对不起，我可以'真的跟着你在这里。 PyPy以什么方式进行类似Java的b $ b $安排？
。如果没有这样一个pypy.NET系统，那就是提供了一个pypy无法提供的服务：
一个（python - > c ++）-conversion可以让我顺利地集成python贡献
与我已经惊人的c ++库
。我不是在暗示pypy应该是另一个用python重写的Mono，因为.NET架构的基本使命是能够编译
任何语言的用户的选择，对某些中间语言的设计比任何人类可读的语言（例如用户可选择的语言）更有效地编译为
用户选择的任何机器语言。 c ++
。也许llvm字节码可以作为这样一种中间语言？
然后llvm可能是新的c ++（我们的事实上的IL（中间语言））
然后可以替换shedskin（python - > IL = c ++）通过组合pypy（python - > IL = llvm）
和所有目标平台的一些激励来开发高度优化的
（llvm - >本机代码） -compiler
- 假设也有可用的高度优化的（c ++ - > llvm字节码）编译器。
PyPy can currently compile Python code to C code and to LLVM bytecode.
Note that even for LLVM bytecode the argument is void since LLVM
(despite its name, which might lead one to think that it is Java-like)
compiles its bytecode to native assembler.
but the primary mission of pypy
is just having a python system that is
written in something like python rather than c or c++
it''s really just plain python (it completely runs on top of CPython
after all) together with some restrictions -- which seem similar to the
restictions that shedskin imposes btw.
. there is no reason why the pypy project can''t have a .NET architecture
instead of the java-like arrangement I assume it has now
Sorry, I can''t really follow you here. In what way does PyPy have a
Java-like arrangement?
. without such a pypy.NET system,
shedskin is offering a service that pypy can''t yet provide:
a ( python -> c++ )-conversion allows me to
smoothly integrate python contributions
with my already-staggering c++ library
. I''m not suggesting that pypy should be another
Mono rewritten in python,
because the essential mission of the .NET architecture
is being able to compile
any language of the user`s choice,
to some intermediate language designed to be
far more efficiently compiled to
any machine language of the user`s choice
than any human-readable language such as c++
. perhaps llvm bytecode can serve as such an intermediate language?
then llvm could be the new c++ (our defacto IL (intermediate language))
and shedskin (python -> IL=c++) could then be replaced by
the combination of pypy (python -> IL=llvm)
and some incentive for all target platforms
to develope a highly optimized
( llvm -> native code)-compiler
-- assuming also, that there is available
a highly optimized ( c++ -> llvm bytecode )-compiler .
那里是。请查看LLVM页面了解详细信息： www.llvm.org
干杯，
Carl Friedrich Bolz
there is. look at the LLVM page for details: www.llvm.org
Cheers,
Carl Friedrich Bolz
Carl Friedrich Bolz写道：
Carl Friedrich Bolz wrote:
。没有理由为什么pypy项目不能拥有.NET架构而不是我认为现在已经有了类似Java的安排
. there is no reason why the pypy project can''t have a .NET architecture
instead of the java-like arrangement I assume it has now
对不起，我可以'真的跟着你在这里。 PyPy以何种方式具有类似Java的安排？
Sorry, I can''t really follow you here. In what way does PyPy have a
Java-like arrangement?
我想这句话是关于及时的。 />
PyPy可能最终使用的编译技术，虽然我在
下，大多数CLR实现也使用这种技术的印象
（并且它有可能如gcj所证明的那样将Java编译为本机代码。
但是关于LLVM的主题：虽然它看起来像一个非常有趣的
和多功能的软件，它似乎也相当困难
来构建;我上一次尝试使旧式gcc引导过程
似乎双击setup.exe。这不是担心PyPy
团队，还是我忽视了一些更简单的方法？ （注意到LLVM 1.4存在Debian
包但不存在1.5。）
Paul
I imagine that this remark was made in reference to the just-in-time
compilation techniques that PyPy may end up using, although I was under
the impression that most CLR implementations also use such techniques
(and it is possible to compile Java to native code as gcj proves).
But on the subject of LLVM: although it seems like a very interesting
and versatile piece of software, it also seems to be fairly difficult
to build; my last attempt made the old-style gcc bootstrapping process
seem like double-clicking on setup.exe. Does this not worry the PyPy
team, or did I overlook some easier approach? (Noting that a Debian
package exists for LLVM 1.4 but not 1.5.)
Paul
这篇关于Shed Skin的第一个版本，Python-to-C ++编译器。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
