2012年5月--CSE部门关于VR 2012的常见信息
2012年虚拟现实应用程序的规划页面。
我们希望在2012年4月1日之前将拨款申请作为内部截止日期（“困难”截止日期为2012-04-12-就在复活节之后）。
公共存储库：（ST部门git回购)
git克隆remote12.chalmers.se:/chalmers/groups/cse集/gitrootcd gitroot/Posposals/VR
在那里的子目录中创建您自己的应用程序（例如JP/代表Jean-Philippes应用程序）。还有一个Notes/目录，其中包含一些会议笔记。
第一次VR总体规划会议：2012年3月8日，星期四，10:00，8103（午餐室）。
第二次会议（主要是关于继续为多项目拨款.
摘要
埃米尔
标题：简化DSL实现
我想努力使它非常容易实施好的DSL。这涉及到
- 结合内部和外部DSL的优点（即嵌入式实现，但对用户来说具有更好的表面语法）
- 继续开发句法，使其更易于使用
作为一个具体的应用程序，我想在Feldspar从事硬件/软件协同设计。这可能会以有趣的方式影响语言及其实现，因此它将为测试通用方法提供一个很好的案例。
我怀疑Feldspar的硬件生成本身就是一个有趣的领域。它可能需要方法（抽象解释、形式验证、测试）来驯服Feldspar的动态方面。我不确定这是否应该是应用程序的一部分。
孟
标题：DSEL的良好反馈
DSEL通常被认为是语言设计和实现的轻量级方法。DSEL表现为一个库，它继承了宿主语言的表达能力，并易于进行实验和定制。通过仔细设计，特定领域的嵌入式编译器可以生成在性能方面与手工编写的基准测试相当的代码。另一方面，这种深度嵌入进一步降低了嵌入式语言向用户提供有用反馈的能力。从生成的代码中产生的消息揭示了实现的细节，用户通常无法理解这些细节。
在非嵌入式语言实现中也存在同样的问题，编译器编写者通常愿意花很长的时间来规避它。例如，在GHC中，类型检查是在编译过程的一开始就执行的，目的是获得良好的错误消息。因此，少数几个足以让核心语言脱颖而出的打字规则爆炸性地得分。这是一个高昂的代价，并不总是适用的。例如，任何关于优化效果的反馈都必须从优化的代码中进行回溯。因此，源信息必须通过程序转换向下流动，来自翻译程序的反馈必须向上流动。
我们在费尔德斯帕对这个问题进行了一些初步研究。我们当前的实现用它们的位置注释各种标记的源表达式，通过程序转换传播注释，并将源位置表示为生成代码块的起源。结果令人鼓舞；尽管源代码和生成的代码在结构上存在很大差异，但在大多数情况下都可以确定精确的源代码来源。我们计划沿着不同的方向进一步发展这种方法。特别是，我们希望能够将信息从生成的代码流回源代码。这有很多优点：在用户只需在域级别工作的情况下，可以在源代码中查看反馈；在用户要通过检查生成的代码来改进源程序的其他情况下，更可取的是能够指向生成代码中的块并标识源位置，而不是尝试推测性地标记源表达式以进行注释，并希望表达式的转换能够达到目标。
为了实现这一点，程序转换需要双向化，以便用反馈信息注释生成的代码可以用于生成源代码。我们在双向编程方面的丰富经验将对此有所帮助。通常，双向化程序是一项困难的任务，因此，可以处理的程序类通常非常有限。然而，在这里研究的具体案例中，我们持乐观态度，因为注释的设计方式不会改变AST的结构。在双向编程术语中，更改此类注释构成了受限更新，这简化了从更改的输出重新生成输入的任务。我们将关注不同类型反馈的建模，包括错误消息、优化结果、分析信息等，以及注释与程序转换的交互方式：理想情况下，添加注释应该不会对现有转换产生任何或很少的更改。
在这个项目中，我们将
- 将各种反馈建模为AST的一部分（与句法相关）
- 调查此类建模对现有程序转换的影响（可能涉及为程序转换设计另一个DS（E）L）
- 设计合适的双向化技术
备注：我的个人提案将更多地介绍双向技术的技术进步。该计划是通过将这些技术应用于DSEL设计，将其与小组提案联系起来。由于双方都还没有确定，我很乐意随着我们的进展调整这个计划。
日本
标题：数学结构并行编程
直到最近，大部分并行编程都是以一种特殊的方式进行的：对于每个问题，都从头开始设计一种新的并行算法。
最近，谷歌通过其地图还原架构推广了另一种方法。如果一个计算被构造为一个关联运算符（幺半群）的重复应用（减少或折叠），那么它可以并行运行，并且可以扩展，几乎没有限制。Fortress编程语言也支持相同的方法。要领会的教训是，并行计算机可以数学建模为只能进行这种特殊折叠的函数。
地图还原方法非常通用：原则上可以应用于任何问题。这非常强大，也意味着程序员对其特定应用程序的支持很少。因此，我们建议在这个通用框架的基础上构建更专业的地图还原方法，而不是基于自由选择幺半群，而是基于更具体的数学结构。脑海中浮现出团体、阿贝尔团体、戒指等。
此外，我们希望帮助程序员使用该框架来正确地显示他们的程序。在这里，我们将一方面建立在随机测试的基础上，另一方面建立在证明助手的基础上。我们的计划是为这两个框架构建特定的库，以代替程序员承担（部分）证明责任。对于校对助理，除了程序骨架库之外，我们还将提供一个证明骨架库，其中可以填充每个应用程序特定的证明部分。同样，我们将提供测试工具来检查所需的属性，如果正确性是次要问题，则可以使用这些工具，或者在编写完整证明之前，将其作为第一步。
