perl6

bloves

建议多关注perl6进展

(这条文章已经被阅读了 93 次) 时间：2002/12/01 12:46pm 来源：风信子


e文好的，最好直接去:
http://dev.perl.org/perl6/
http://dev.perl.org/
查看。

linuxforum.net的DanceDanceDance翻译了一些文字转贴过来，做个引子。

-------------------------------------------------------------------------------------
Perl6的结构

摘要

源码进入解释器，解释器产生一个语法树（syntax tree）。
语法树进入编译器，编译器产字节码(bytecode)。
字节码进入优化器(optimizer)，优化器产生更多的（更好的）字节码。
Runtime然后来处理进入的字节码（可能是运行它，不过也有可能把它转化为Java字节码，或者.Net字节码，或者可执行的Alpha 代码（an alpha executable），或者编码的DNA序列）。

Source Code
+----------------+
|The Parser |
+----------------+
Syntax Tree
+-------------------+
|The Compiler |
+--------------------+
Bytecode
+---------------------------+
|Byteode Optimizer |
+---------------------------+
Better Bytecode
+------------+
|Runtime |
+------------+

计划
解释器将允许你改变这些规则。规则集(rule sets)定义了主要的语言(Perl, C, Python, Java, etc.)，你可以为其他的语言撰写新的规则(比如，没有$ @ %等符号的Perl)。

运行时引擎(the runtime engine)将会时一个基于寄存器的虚拟机(a register-based virtual machine)，而perl5的虚拟机时基于栈的(stack-based)。

重写(revisit)Perl的一个主要原因是要去修复混乱的XS(XS是指用C/C++子程序来扩展Perl)的方式。除了用来执行Perl的函数，Perl5没有用于扩展的API，所以扩展Perl需要大量繁琐的工作。Dan和Larry的目标是要使C扩展的使用尽可能的简单（Brian Ingerson的精彩的Perl5内联模块为此指明一些方向）。任何使用过XS的人都等着它的灭亡。

Perl5被设计成这样一种方式，那就是当有C的时候，它就可以运行。近来，一些虚拟机(JVM, .NET)代替了C。所以，我们将看到，我们的自己的虚拟机不仅可以在有C的时候运行，而且同样可以方便的将字节码输入到其他的虚拟机。


-------------------------------------------------------------------------------------

Parrot 常见问题  [re: fgh]     



////////////////////
//一般性问题//
////////////////////
#什么是Parrot?
Parrot是为支持Perl6语言而新设计的解释器。它被设计成一种独立的虚拟机，可以用来执行从Perl5,Perl6等动态语(dynamic languages)编译成的字节码。理想中，Parrot能够支持其他的动态，被编译成字节码(bytecode-compiled)的语言，如Python, Ruby和Tcl。

#为什么叫Parrot?
Parrot来源于Simon Cozens的愚人节玩笑，说的是Larry Wall和Guido van Rossum宣布Perl和Python将合并。

#Parrot就是Perl6吗？
否！Parrot是用来执行Perl6程序的。Perl6语言的定义正在被Larry Wall加工。Perl6的真正状态仍然是一个迷，她会和今天我们看到的Perl充分的相似，以及需要一个运行时系统。

#今天我能够使用Parrot吗？
当然！Parrot正处于她执行的早期阶段。使用Parrot最主要的方式是去写Parrot的汇编代码。你可以在Apache中使用Ask Bjorn Hansen的mod_parrot模块来建立动态内容(dynamic content)。不过千万不要用于产品的代码中，那只是一个玩具。

#为什么我要用Parrot汇编代码编程？
很多的原因：
*所有的人都在这么做
*It's a neat hack.
*你能够享受是用汇编编程的乐趣而不必担心系统的崩溃
严肃的说，使用Parrot汇编语言是一种充满乐趣的挑战，同时也是用来测试Parrot的最好的方式。

#什么时候才能通过一种“真正”的编程语言来使用Parrot？
这要看你是怎么看“真正”这个词了。
*Leon Brocard发布了一个Java字节码到Parrot字节码的编器。
*Gregor Purdy正在进行一种能够直接面对Parrot字节码的小语言Jako的方面的工作。
*Dan Sugalski和Jeff Goff已经开始了将Scheme编译成Perl 字节码方面的工作。

#Parrot是用什么语言写的？
C.

#Why not write it in insert favorite language here?（不晓得如何翻译insert favorite language）
Becuase of one of :
*Not available everywhere.
*Limited talent pool for core programmers.
*Not fast enough

#你为什么不使用外部工具或者X库(library X)?
*许可证兼容性(License compatibility)
Parrot有着一个古怪的许可证--她目前正在使用和Perl5同样的许可证，这种许可证是GNU GPL和Artistic 许可证的分离，可以简写成Artistic | GPL。因此，Parrot的许可证和GNU GPL兼容，这意味着你可以把Parrot同GPL代码相结合。
能够进入核心解释器的代码必须归入与Parrot一致的条款。我们连接进入解释器的库代码(比如，用于Unicode的ICU库）能够被其他的许可证代替，只要他们自己的条款不禁止这样做。
*平台兼容性
Parrot必须工作在所有的Perl5的平台上，以及少数特别的平台。Perl5可以在80个平台上运行；Parrot必须在Unix, Windows, Mac OS(X and Classic), VMS, Crays, Windows CE, and Palm OS等等。而她的处理器的构架将会是x86, SPARC, Alpha, IA-64, ARM, 和68x00(Palms and old Macs).如果某些东西不能在其中的一个平台/操作系统中工作，我们就无法在Parrot中使用它。
*速度，大小和适应性
Parrot不仅应该能够，而且应该是高效的在这些平台上工作。根据不同编译器，Parrot的核心大小是在250K到700K之间。这样她就能够在掌上系统上运行了。任何Parrot使用的库必须足够快，几乎不存在性能的冲突；必须足够小，几乎不存在核心大小上的冲突；足够强的适应性，能够处理如Perl, Python, Tcl, Ruby, Scheme等的各种要求。

#为什么用你们自己的虚拟机，而不是编译成JVM/.NET?
那些虚拟机针对静态类型语言的(statically typed languages)。比如Java, C# 和许多其他的语言都是静态类型语言，而Perl不是。由于各种各样的原因，意味着Perl若要是在那些虚拟机上运行会慢的多，所以针对Perl这样的动态语言(dynamic language)我们设计了专门的解释器。

#那么，你们不能在JVM/.NET上运行了？
当然不是。他们不是我们的第一目标。我们首先建立自己的解释器/虚拟机，然后才会开展基于JVM,.NET的工作。

///////////////////////////////////
//PARROT AND PERL//
//////////////////////////////////
#为什么重新实现Perl?(Why re-implement Perl)
好问题！
在2000年夏天，Larry wall宣布是到了从新开始建立Perl的时候了，这包括Perl语言，语言的执行，那些志愿去实现和维护语言的源码社区的开发者，以及更大的使用Perl的程序员社区。
很多的原因促使我们开展的这个计划：
*Perl5是一个稳定的，可靠的，健壮的开发平台；她还很年轻，到Perl6正式发布的以后。(证据：Perl4依然坚强的活着，而其实我们都想让她消失）
*若有需要，我们有将Perl5转化成Perl6的能力。这保留了向后的兼容性。
*语言有修改的必要(The lauguage can stand some revision)：格式并不属于核心语言， typeglobs have outlived their unsefulness。通过修改语言，我们能使Perl更好。
*一些瑕疵应该被除去：一旦成功，系统应该返回TRUE来代替FALSE，localtime应该返回year 而不是 year-1900。
*用Perl代替C来写Perl编译器是一件非常好的事情.

#你想用Perl来写Perl编译器？
当然！C, Java, Lisp, Scheme……实际上所有的其他的语言都是self-hoisting 的！

#Parrot如何一起处理Perl5和Perl6?
我们还不清楚，这将依赖于Perl6语言的定义。但是，我们或许会根据编译的是Perl5还是Perl6来选择使用两个不同的Perl编译器。Larry曾经说过或许会使用一个package statement来声明该文件是Perl5，但具体怎么做，我们也不清楚。

#这将是Parrot运行Python, Ruby和Tcl代码的方式吗？
或许

-----------------------------------------------------------------------------------
启示录1：丑陋的，坏的和好的 （上）

Apocalypses I: The Ugly, the Bad, and the Good
By Larry Wall
April 02, 2001

当听到启示录这个词的时候，人们往往会感到害怕，但是此时，我赋予了它好的意思：启迪。用好的思想来启迪好的人，这就是启示录的作用。

在这篇文章里面我要揭示的，是关于Perl6的设计。或者，更精确的说，是最初的设计，因为，在当我把我最初说的话付诸于实际之后，设计过程会依然进行。我不是一个先知，同上帝的游戏对我来说有些难以承受。但无论如何，有些人必须去这么做，所以，我会尽我的全力。我希望你们所有人能够帮助我来创造历史。

“如果你着眼于Perl6的历史，你就能发现为什么这篇文章的幅标题是“丑陋的，坏的和好的”了，从好的意义上来说，去年的RFC过程(RFC=The Requests for Comments )甚是丑陋。它是一个自由讨论的过程(brainstorming process)，这就意味着它的丑陋——并不是指粗野，因为RFC过程实际上是相当文明的，而是指在RFC中的各种意见是些毫无联系的构思。坦白的说，RFC完全偏离了原来的计划。(Frankly, the RFCs are all over the map, without actually covering the map)。有的RFC是矛盾的，而有的RFC丢失了。很多的RFC本来着眼于现实的问题但却用好笑的角度试着提出解决方案(Many of the RFCs propose real problems but go off at funny angles in trying to propose solutions)。

我也发现了Larry的语言重新设计的第一准则：Everyone wants the colon.

刚才讲的是丑陋的部分。而坏的部分是我被期望获取这些RFCs，在两个星期内建立起一个一致的设计方案。开始的时候，我打算将那些RFC分成好的，坏的和丑陋的三类，而最终，他们中的大多数被归为了丑陋的，因为好的那些通常存在一些错误，而即使坏的那些通常指出了一个问题，其思想还是不错的，即使，这个解决方案完全就是杜撰的。

现在，五个月过去了，我一直都在思考一致性（连贯性）的问题。你们很多人都知道，当你的Perl程序超过了你的物理内存的时候什么会发生——你开始抓狂了。我也会这么做。我无法很好的一次在头脑里面处理很多的问题，而且我不是一个善于细分问题的人。我的长处在于综合，而非分析。我无法忍受生活中有许多让我分心的事情，有一些是我自己造成的，有一些不是。我不会更多的谈这些。留在我的还未发表的自传里面吧。
但是现在，我们谈谈好的部分。（我希望）经过考虑了许多许多单独的RFCs，不知道如何开始将他们作为一个整体来思考，我终于发现了用来思考这些问题的恰当的顺序，或多或少，就是Camel Book（应该是指Programming Perl, 3rd Edition，译者注）的章节的顺序，用大概同样的顺序来思考Perl6，将减少在我已经决定之前必须去决定的事情（比较绕口，原文：...,so considering Perl6 in roughly the same order will tend to reduce the number of things that i have to decide before i've decided them.)

所以，我已经愉快的将所有的RFC按照章节顺序进行了分类，现在，他们看起来更容易管理了。我打算为每一章写一个“启示录”，所以，启示录I将对应着第一章：Perl概述(An Overview of Perl)。（当然，在这本书中，“概述”更象一个短小的教程，而非真正完整的分析Perl的哲学基础。）
所以今天，我将谈谈下面的RFC:

RFC PSA Title
--- --- -----
16 bdb Keep default Perl free of constraints such as warnings and strict.
26 ccb Named operators versus functions.
28 acc Perl should stay Perl.
73 adb All Perl core functions should return objects.
141 abr This Is The Last Major Revision.

PSA等级代表着"roblem（问题）, Solution（解答）, Acceptance（接受）".问题(problem)和解答(solution)的等级为a-f, 通常，你将发现我对问题(problem)的评级高于解答(solution)。接受(acceptance)评级是以下之一：

a Accepted whileheartedly
b Accepted with a few "buts"
c Accepted with some major caveats
r Rejected

某些时候，我会用d表示延期(Deferred)，如果我真的认为有些东西不应该过早决定。

RFC 141: This is The Last Major Revision

最初，我倾向于接受这个RFC，但是最终，在神学的立场上(on theological grouds)，我决定否决它。在关于启示录的文学作品中，7是一个代表完美的数字，而6则代表着瑕疵。实际上，就像RFC暗示的，我们可能不会结束对2*PI这样一个版本号的收敛，不过不是6.6.6这样一个倒霉的数字。(In fact, we probably would not end up converging on a version number of 2*PI as the FRC suggests, but rather on 6.6.6, which would be rather unfortunate)。

所以，Perl7将是最后一个主要的修订版本。实际上，Perl7将会非常完美，它将不会再需要任何修改。Perl6就是Perl7的原型。:-)

实际上，我同意这个RFC的潜在的情感——我只是出于其娱乐成分而否决了它。我想让Perl继续演变，能够更好的解决问题。出于那样的原因(to that end)，如果你细读RFC，你会发现我的一些设计目标并非十分的清晰。

首先，Perl将会支持映射于单语义模型(single semantic model)的多重语法(multiple syntaxes)。其次，单语义模型将会反过来映射到多平台。

多重语法听起来象一个邪恶之物，但是他们对于语言的演化是非常需要的。某种程度上来说，我们已经有了多重语法模型；每次你使用一个pragma或者module，你就在扭曲你正在使用的语言。只要在module的开头声明是清晰无误的，这就没有问题。

有一个例子是很特别的，它能用来说明支持多重语法如何允许(Perl的)继续的演化，那就是从Perl5移植到Perl6本身。详见下面关于RFC 16的讨论。

Multiple backends对于我们如今居住的世界很重要。Perl6绝对不能限制在那些能够进行C编程的平台上运行。它必须能够在其他的虚拟机上运行，比如说那些支持Java和C#的。