Proxima：一个面向表示的结构化文档编辑器

Tuesday, January 11, 2005

Proxima : a presentation-oriented editor for structured documents

 

一篇有趣的论文里曾提到过，在未来，将有大量的应用软件会基于泛型编辑框架进行定义，就像这个一样。

Proxima原型（prototype）是在Haskell下编写并使用wxHaskell创建GUI。它将一个幻灯片编辑器、一个棋盘（chess board）、一个公式编辑器和一个Haskell源码编辑器整合到一个单独的多功能编辑器中，以此证明其灵活性。

可真正有意思的，是它很像我一直在这讲到的GUI约束维护之类的东西，因为它需要处理一个数据（这里原文用到”fact”一词，推测其为”数据”之意。-译者注）的不同版本以及变更为一种数据类型的可能性，而这种数据类型可能不会立即具备可译性而变为其他数据类型。

当然，他们在说到这时并没有谈及这些。他们在谈论“标准（level）”，是总体上符合其文本或绘画格式、AST和注释语义AST的一个文档的交替格式。每个标准可能会变更，而这种变更不能与其它标准合成到一起。比如可能是因为你录入时所写的东西并不符合语法规范。系统使用各种声明性的微型语言来表示标准间的转变，使得创建一个新的编辑器一般都要求对每个相关转换语言指定其样式表的类型。

我没有深入研究过这个，主要因为它与Haskell联系太紧密了（基于Haskell的），包括转换语言。所以我打算学一点Haskell，以便理解他们到底在做什么。总之，它已经让我思考很多东西了，比如怎样在GUI中实现一个“选择”的功能，我常常在PEAK邮件列表上讲有关基于泛型函数GUI框架，在这一方面这个问题就显得有点价值。

似乎他们的原型现在对于较大的文档没有用武之地。很明显，当前的实现使用了非增量属性语法，这意味着即使一些很小的改变也能引发内部结构大范围的重新计算。当然，这是在我所试图设计的东西中所要避免的。更确切地讲，我对被称作声明性代码的“自动划分”比较好奇，它将诸如约束或转换的声明性概念转变为事件驱动代码，使得数据库发生变化时派生（derived）数据也随之变化。

Proxima具有一些前面提到的特性，但更有意思的额外约束是它必须支持双向性。也就是说，并没有真正固定的“基准”和“派生”，任何你更改的数据都是“基准”，而其它数据就是“派生”的！在基于数据（fact-based）的系统上我想试着在一定程度上实现这种思想，在任何一个数据类型之间含有一对一对应关系的地方，即使是出现“特别状态”的时候。（“特别状态”是Proxima的术语，用于只能使用一种表达方式的数据，类似不在AST中出现的文本注释或不显示的类型信息）

 

（原文链接网址：http://dirtsimple.org/2005/01/proxima-presentation-oriented-editor.html）