创建“Europanto”的障碍是什么？类型通用脚本语言？

发布于 2024-07-06 22:59:16 字数 917 浏览 6 评论 0原文

本周在几种脚本语言之间来回切换后，我发现自己在想它们是多么相似。然而，我总是求助于 Google（或者现在的 SO）来记住细节，例如“instanceof”和“endswith”的本地等效项是什么，或者声明接口的正确语法，等等。

这让我想起了（人类）语言 Europonto。只需选择一些模糊的英语语法和一些模糊的浪漫/日耳曼/斯拉夫词汇，一切都很好！

那么如果我们尝试使用脚本语言做同样的事情会发生什么。今天想了解 Python 风格的缩进块吗？美好的！想要使用原型对象吗？好的！只能记住如何拼写某些库函数的 PHP 名称？没问题！

无论如何，这是一个疯狂的想法。由于我们需要一个可以提供具体答案的问题，所以让我们像这样收紧它：

创建一种允许 [Python、Ruby、PHP、Perl、shell、和 JavaScript]，以便您可以在语言之间自由混合代码块和函数名称？

假设任何特定的构造在语句级别都应该保持一致。因此，我们将允许：

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
}

但不允许，

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
   endif
end

冲突可以包括：解析器歧义；名称冲突；对象、函数或闭包的语义冲突；我猜范围将是一个巨大的问题，但你告诉我。

我将从一开始就将其作为“社区维基”开始，所以如果您认为这是一个有趣的问题但想让它更加严格，请随意编辑。

原文

After switching back and forth between several scripting languages this week, I found myself thinking how similar they all are. Yet I'm always reaching for Google (or nowadays SO) to remember details like what the local equivalents of "instanceof" and "endswith" are, or the right syntax to declare an interface, or whatever.

This reminded me of the (human) language Europonto. Just pick some vaguely English syntax and some vaguely Romance/Germanic/Slavic vocabulary, and it's all good!

So what would happen if we tried to do the same thing with a scripting language. In the mood for Python-style indented blocks today? Fine! Want to use a prototype object? Ok! Can only remember how to spell the PHP names of some library function? No problem!

Anyway, that's the wild and crazy idea. Since we need a question that admits concrete answers, let's tighten it up like this:

What would be the most significant conflicts in creating a scripting language that permitted all the native syntax and library functions of [Python, Ruby, PHP, Perl, shell, and JavaScript], such that you could freely intermix code blocks and function names between languages?

And let's say that any particular construction should be consistent at the statement level. So we'll allow:

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
}

but not, say,

foreach( $foo as $bar )
{
   if $foo == 2:
      print "hi"
   endif
end

Conflicts can include: parser ambiguities; name collision; conflicting semantics for objects or functions or closures; etc. I'm guessing that scope will be a ginormous issue, but you tell me.

I'll start this as "community wiki" from the get go, so if you think it's a fun question but want to make it more rigorous, feel free to edit.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

删除会话 2024-07-13 22:59:16

我建议主要问题是识别每个语句的语法应该是什么。

无论如何，这有什么意义呢？几乎所有脚本语言都具有执行相同操作的功能，这就是为什么人们倾向于掌握一种他们一贯使用的脚本语言，并坚持使用它。

回复收藏 0 原文

寄风 2024-07-13 22:59:16

主要的困难是让人们维护它。使用定义良好的语言，您只能以某种方式打印并以某种方式执行sys.argv。一旦您允许使用多种语法，就没有明智的方法来搜索您拥有的代码库中的所有 sys.argv 。

回复收藏 0 原文

慵挽 2024-07-13 22:59:16

在语法级别，我看到的唯一问题是检测哪个块具有哪种语法，然后将它们分开并使用特定的解析器解析它们。当然，鉴于非常小的陈述，对于它是哪种语言可能会存在歧义，您可能会认为这并不重要，但情况可能就是这样，在不同的语言中，相同的字符串会执行不同的操作，因此< em>可能是一个微妙的问题。

在API级别，您可以使用许多不同的方法来完成同一件事，但方式或子集略有不同。例如，您可能无法在 PHP 中执行 Java 的 string.startsWith()，因此您将执行不同的操作，或者无法执行 PHP 的 strstr() > （它返回从找到的针到末尾的字符串的一部分），您将为此实现不同的东西，甚至以不同的方式思考问题。那么您就必须拥有所有这些不同的 API 方法来做同样的事情，这将是一个巨大的 API 需要实现、支持和（上帝禁止）学习。

在湿软件级别，除非您了解大量语言及其细微差别，否则其他人编写的代码将完全无法阅读。我认为学习一种编程语言到最小的细节已经够困难的了，所以创造这种弗兰肯斯坦式的野兽根本不切实际。我可以想到一个例外，用作算法描述语言，它已经在世界各地的大学中使用，教师采用他喜欢的某种语言，并使代码对人类来说尽可能可读，而无需实现它的解析器。

顺便说一句，我认为这种系统可以通过以某种方式利用 .NET 的 CLR 以最少的努力实现，其中您有大量不同的语言，每种语言都编译为相同的语言字节码并访问相同的变量和内容。 您需要做的就是将代码拆分为不同语言的集群，然后在各自的编译器上单独编译它们，然后合并字节码并以某种方式确保它们当在不同语言中提到相同的名称时，它们都指向相同的变量和函数。

At the syntactical level the only problem I can see would be to detect which block has which syntax, then separate them and parse them with specific parsers. Of course given very small statements there could be ambiguities as to which language it is and you could argue that it doesn't matter, but it just may be the case, that in different languages the same string of characters does different things so this could be a subtle issue.

At the API level you would have lots of different methods of doing the same thing but in a subtly different way or subset of doing it. So for example you could have no way of doing Java's string.startsWith() in let's say PHP, so you would do something different, or no way of doing PHP's strstr() (which returns a part of the string from the found needle to the end) and you would implement something different for that or even think differently about the problem. Then you would have to have all those different API methods of doing the same things and that would be huge API to implement, support and (god forbid) learn.

At the wetware level the code written by others would be totally unreadable unless you know a ton of languages and their subtle differences. I think it is difficult enough to learn a single programming language to the smallest details and so it is not practical at all to have this kind of frankensteinish beast created. I can think of an exception for use as an algorithm description language which it already is used in universities all over the world, where teacher takes some language of his liking and makes the code as readable as it can be for a human without needing to implement a parser for it.

As a side note I think this kind of system could be implemented at the least effort by somehow utilizing .NET's CLR where you have a ton of different languages each compiling to the same bytecode and accessing the same variables and stuff. All you'd need to do is split the code to clusters of different languages, then compile them separately on their respective compilers and then just merge the bytecode and somehow make sure they all point to the same variables and functions when mentioning the same names across the different languages.

回复收藏 0 原文