language-design - 在底层语言中实现脚本语言核心方法的优点和缺点

Question

背景:我正在编写一个脚本语言解释器，作为测试一些实验性语言想法的方法。我即将为内置类型编写一组核心标准方法(函数)。其中一些方法需要直接与底层数据结构交互，并且必须使用底层语言编写(在我的例子中是 Haskell，但这对于这个问题并不重要)。如果我选择，其他可以用脚本语言本身编写。

问题:用底层语言或语言本身实现核心库函数有哪些优点和缺点？

示例:我的语言包含内置类型数组，其工作方式就像您想象的那样 - 分组在一起的有序数据。 Array 实例(这是一种 OO 语言)具有方法 inject、map 和 each。我已经在 Haskell 中实现了注入(inject)。我也可以用 Haskell 编写 map 和 each，或者我可以使用 inject 用我的语言编写它们。例如:

def map(fn)
    inject([]) do |acc,val|
        acc << fn(val)
    #end inject
#end def map 

def each(fn)
    inject(nil) do |acc,val|
        fn val
    #end inject
#end def each

我想知道每种选择的优点和缺点是什么？

Answer 1

主要优点是你吃的是自己的狗粮。您可以用您的语言编写更多代码，从而更好地了解它的样子，至少对于通用库代码来说是这样。这不仅是一个发现语言设计缺陷的好机会，也是发现实现缺陷的好机会。特别是，您会发现更多错误，并且会发现是否可以有效地实现此类抽象，或者是否存在迫使人们用另一种语言编写性能敏感代码的基本障碍。

这当然会带来一个缺点:无论是在程序员时间还是在运行时性能方面，它可能会更慢。然而，第一个对你(语言设计者)来说是宝贵的经验，第二个应该是优化实现的激励(假设你关心性能)而不是解决问题——它削弱了你的语言并且不能解决同样的问题对于无法修改实现的其他用户。

对于面向 future 的实现也有优势。在面对底层的重大修改时，该语言应该保持稳定，因此在执行这些修改时，您必须重写更少的代码。相反，这些函数将更像其他用户定义的函数:存在一个真正的风险，即在实现语言中定义某些标准库函数或类型时，细微的差异会潜入其中，使类型或函数的行为方式可能会受到影响。不被语言模仿。