人工智能，XML和Java并发

自动编程应用程序中被处理成的XML的源代码将会以XPL（可扩展流程语言）的形式进行创建和维护。XPL的结构与XML相似，但解析器允许在文本元素中使用XML的特殊字符（<，＆，>，“，”），这在处理源代码时提供了明显的优势。并且它可以同时运行向XML的转换流程也是一个消除预处理的性能成本的策略。

背景

高级逻辑项目（The High Level Logic Project）始于20世纪80年代早期的思想实验，它是因第一次大规模人工智能商业化努力中的瓶颈和性能问题诞生的。其结果是产生了用Java编写的非常高级的框架，用于简化高性能智能分布式系统的开发。该项目目前正处于商业化的初期阶段。

XML一直是该项目的关键技术。例如：通过允许使用配置进行定制而不是重写程序来鼓励软件组件的可重用性（就像配置服务器应用程序一样。）。和许多现代项目一样，XML也用于分布式系统之间的通信。流行的编程语言对XML处理有很好的支持，并且XML为大量专业程序员所熟悉; 在开发用于商业的框架时需要考虑的重要模块会尽可能多的使用XML也意味着更频繁地重复使用处理组件，从而有助于构建和维护更加快速，高效，轻量的系统。

AI和XML

人工智能处理通常涉及将逻辑视为数据。这可以让程序“思考”它正在做什么，并在运行中进行更改。在某些情况下，这涉及将源代码片段实际存储为文本数据，随时配置其使用，然后解释代码或将结果推送到编译的自动编程过程中。

XML几乎是将代码片段存储为文本的完美选择。除了有很好的支持和开发人员对此熟悉之外，标签名称可以匹配处理程序情况，名称空间可以立即处理某些上下文元素，属性可以提供有关特殊处理要求（类型等）的信息。将源代码片段存储在XML文本元素中将会非常棒。但是这直接导致我们直接进入XML的特殊字符处理问题。

源代码包装XML时为XML相关过程预留的“特殊字符”（<，＆，>，"，'）。XML是为标记而非代码存储和处理而设计的，我们需要更方便的东西;源代码存储以其通用的，未经修改的形式存在，而不会导致文件体积更大，可读性更差或难以维护。然而，出于原因，我们不想放弃XML。

XPL，如同给源代码的XML一样

如果我们有一个可扩展过程语言，会不会很好？XPL看起来就像XML，但在文本元素中不会有特殊的字符限制。是的它真实存在。XPL是高级逻辑项目针对特殊字符问题的解决方案。XPL看起来像XML，但允许在文本元素中使用特殊字符：

<?xpl version="1.0" encoding="utf-8"?>
<mycode xmlns="http://xmlns.hll.nu/rules" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0">
 <state name="dum1" type="int" value="3" />
 <state name="dum21" type="String" value="dum11" />
  <!--  My first rule  -->
  <rule>
    <if> dum1 <5 && dum1 > 1 || dum1 < 200;</if>
    <then>
      dum21 = "Unescaped special characters like '<' can be used."
    </then>
  </rule>
</mycode>

XPL的处理是在名为StAX-PL（用于XPL的流API）的过程中使用拉式解析器，因为它就像XML StAX（用于XML的流API）。与StAX一样，StAX-PL非常快速并且轻量。StAX-PL实际上比StAX更轻量，因为它支持的功能更少。在简单的处理中，XPL可以用来代替XML。当需要全功能的XML处理时，StAX-PL是生成可用XML的预处理器。这样我们就有XML和XPL这两者的几乎所有优点。我们可以将源代码存储在XML结构中，而不会面临项目致命性的不便。

瞬间预处理！

性能问题已经成为更广泛使用人工智能技术的严重负担。“思考”想法，更新，动态适应。人工智能的额外复杂性可能会严重减慢速度。商业级AI需要兼容通用系统开发并具有竞争力。处理速度是一个不变的问题。XPL给我们提供了我们需要的数据表格，但这是以额外的处理时间为代价。StAX-PL速度非常快，可以完全消除这个成本。

在很多情况下，在实时运行期间不需要进行预处理。如果在实时运行期间没有理由更改初始代码数据，则可以提前生成有效的XML。无需通过预处理来加载实时运行。在一些自动编程案例中，甚至不需要XML文件。编译的程序在实时运行期间使用。从XPL到编译代码的过程是开发的一部分（由HLL开发引擎自动完成）。

似乎最常见的情况可能发生在开发，维护和端到端测试期间。框架是在这些活动的服务中创建的，所以这是足够的理由来采取额外的步骤来加快速度。编写工具的开发者还必须尊重应用程序开发人员和操作人员对事情运行方式作出最终判断的事实。灵活性很重要。我们可以认为速度是一件好事。（该项目还涉及包含实时更新的用例，但最好留给单独讨论。）

使用Java并发

StAX-PL使用拉式解析器。SAX使用推送解析过程，其中输入被压入SAX处理栈。这两个过程同时运作良好。StAX-PL非常快速地从XPL解析器中提取元素，并将它们推送到SAX栈。由于StAX-PL所做的工作是有限的，因此要在较重的SAX处理之前保持领先并不困难。即使对SAX的要求相对较低，StAX-PL（如XML StAX）在速度方面也颇具竞争力。

Java语言和JVM旨在支持并发编程。除了使用StAX-PL作为初始源代码之外，Java 7和Java 8的HLL实现的技术细节并非唯一。StAX-PL和SAX进程在单独的线程中运行，StAX-PL的输出直接传送到SAX。（PipedOutputStream - > PipedInputStream）

典型的编程器时序大多是在英特尔双核计算机上进行的，在处理开始之前和完成之后记录系统时间（以毫秒为单位）。测试包括多次运行以滤除系统状态差异。完成（读取过程写入）StAX-PL过程和完整的SAX过程需要分开时间，然后与并行的StAX-PL / SAX过程进行比较。

SAX处理受到限制，大约相当于StAX-PL处理。StAX-PL读取并解析XPL文件和管道元素到SAX。SAX在其堆栈中收到有效的XML元素，重新解析它们，并撰写摘要信息。所有这三个过程（单独使用StAX-PL，单独使用SAX，以及两者结合）所花费的时间几乎完全相同，这证实了Java并行性在消除预处理性能成本方面的成功。

关于StAX-PL

XPL开发者套件可以从高级逻辑项目中获得。该套件包含用于XPL处理的源代码以及用于XML StAX，SAX和DOM的快速启动源代码。还包含并发StAX-PL / SAX的源代码。

免费的XPL命令行工具也可从XPL文件中产生有效的XML文件。