和SO上的很多人一样，我经常使用多种语言编写代码。在规划任务（甚至回答SO问题）时，我实际上是用一种未指定的混合语言思考和写作的。虽然我过去被教导使用流程图或类似UML的图表来做这件事，但现在回想起来，我发现“我的”伪代码语言包含了C、Python、Java、bash、Matlab、perl、Basic的成分。我似乎会无意识地选择最适合表达概念/算法的惯用语法。
常见的惯用语法可能包括Java风格的大括号用于作用域，pythonic列表推导或缩进，C++风格的继承，C#风格的lambda表达式，matlab风格的切片和矩阵运算。
我注意到，人们实际上很容易识别出我想要做什么，也很容易将它智能地翻译成其他语言。当然，这一步需要考虑边缘情况，以及每种语言表现出特性的时刻。
但实际上，大多数这些语言共享一个关键字和库函数的子集，这些关键字和库函数通常以相同的方式工作 – 数学函数，类型名称，while/for/if等。显然，我必须排除许多“奇怪”的语言，如lisp，APL衍生物，但是…
所以我的问题是，
-
是否已经存在可以识别文本文件的编程语言的代码？（当然，这肯定比eclipse的语法树或google translate的语言猜测功能简单得多，对吧？）实际上，SO的语法高亮器是否做了类似的事情？
-
是否理论上可以创建一个单一的解释器或编译器，它可以识别你在任何时候使用的语言习惯用法，并（可能“智能地”）执行或翻译成可运行的形式。并且标记出我的语法在行为方面存在歧义的边缘情况。我看到的直接困难包括：知道何时在依赖缩进和依赖大括号的模式之间切换，识别有趣的运算符（如
*pointer与*kwargs），以及知道何时使用列表与类数组的表示。 -
是否存在任何语言或解释器，可以管理这种灵活的解释？
-
我是否忽略了使这成为可能的明显障碍？
编辑
感谢大家的回答和想法。我计划编写一个基于约束的启发式翻译器，它可以潜在地“解决”代码的预期含义，并翻译成真正的python代码。它会注意到来自许多常见语言的关键字，并将使用语法线索来消除人们意图的歧义 – 比如间距、括号、可选的辅助词（如let或then）、变量先前使用的上下文等，以及对常见约定的了解（如大写名称、i用于迭代，以及对变量/方法的命名的一些简单有限的理解，例如包含单词get、asynchronous、count、last、previous、my等）。在真正的伪代码中，变量命名与操作本身一样具有信息量！
使用这些线索，它将对每个操作的实现做出假设（如基于0/1的索引，何时应该捕获或忽略异常，哪些变量应该是const/global/local，从哪里开始和结束执行，以及哪些位应该在单独的线程中，注意到数值单位何时匹配/需要转换）。每个假设都会有一个给定的确定性 – 该程序会列出每个语句的假设，因为它将你编写的内容诱导成可执行的东西！
对于每个假设，如果你不喜欢最初的解释，你可以“澄清”你的代码。库的问题非常有趣。我的翻译器，像一些IDE一样，会读取所有模块中可用的所有定义，使用一些关于哪些类/方法使用最频繁以及在什么上下文中使用的统计数据，然后进行猜测！（在程序中添加一条注释，说明它为什么这样猜测…）我想它应该尝试执行所有内容，并警告你它不喜欢的内容。它应该允许任何事情，但如果你含糊不清，它会让你知道几个替代解释是什么。
在它能够管理像@Albin Sunnanbo的ImportantCustomer示例这样不寻常的例子之前，肯定还需要一段时间。但我会让你知道我的进展！
回答：
- To detect what programming language is used: Detecting programming language from a snippet
- I think it should be possible. The approach in 1. could be leveraged to do this, I think. I would try to do it iteratively: detect the syntax used in the first line/clause of code, “compile” it to intermediate form based on that detection, along with any important syntax (e.g. begin/end wrappers). Then the next line/clause etc. Basically write a parser that attempts to recognize each “chunk”. Ambiguity could be flagged by the same algorithm.
- I doubt that this has been done … seems like the cognitive load of learning to write e.g. python-compatible pseudocode would be much easier than trying to debug the cases where your interpreter fails.
- a. I think the biggest problem is that most pseudocode is invalid in any language. For example, I might completely skip object initialization in a block of pseudocode because for a human reader it is almost always straightforward to infer. But for your case it might be completely invalid in the language syntax of choice, and it might be impossible to automatically determine e.g. the class of the object (it might not even exist). Etc.
b. I think the best you can hope for is an interpreter that “works” (subject to 4a) for your pseudocode only, no-one else’s.
Note that I don’t think that 4a,4b are necessarily obstacles to it being possible. I just think it won’t be useful for any practical purpose.
