我正在考虑this post关于静态和动态类型语言之间的差异，以及从this reference采用以下定义的注释：
静态类型经常被误解为意味着值与CompileTime中的类型相关联，而相反它意味着ReferenceValue明显地（与CompileTime不同）约束于值的类型可以表示，语言实现无论是编译器还是解释器，都会尽可能强制执行和使用这些约束。
如果我没有错，这个定义指出，是否静态输入并不取决于是否有（或没有）语言的编译实现。
但是用这种方式说，使用静态类型系统进行解释实现有什么好处？我的意思是，检查总是在运行时进行。
答案 0 :(得分：0)
您的问题有几个方面。
第一个我要说的是，静态类型代码与解释的动态运行时的组合是最常见的，作为现有动态语言的补充解决方案。 JavaScript，Python和Racket / Scheme / Lisp都有静态类型检查的变体*。所有这些仍然使用原始语言的运行时。静态类型检查为程序员提供值，即使运行时引擎实际上没有使用静态类型信息。
第二个方面是我认为您引用的定义可能引用的内容。虽然一些静态语言在编译时会丢弃类型信息，并且仅使用它来使代码不必检查类型，但其他语言（如Java和C＃）会保留类型信息以供运行时使用。静态类型检查静态的原因是它可以在不执行代码的情况下完成。可以在运行时进行额外的检查（例如在Java中导致ClassCastException的检查），然后进行动态类型检查（基于静态类型代码的信息完成）。
至于为静态类型语言实际创建解释实现的好处：编译器很难。不像以前那么难（例如LLVM的兴起），但通常比解释运行时的原型设计更难。如果您正在尝试使用高级类型系统，则可能更容易解释第一个实现。如果它是静态类型检查，那么您将有一个单独的类型检查阶段而不执行代码。这可能使运行时不必担心在实际执行代码期间检查类型。
*：TypeScript，Flow，mypy和Typed Racket提及一些。
编辑：评论中提到的示例。新泽西州的标准ML（SML / NJ）是静态类型语言标准ML的翻译。采取以下非常简单的计划：
val _ = print "hello\n";
val foo : string = 4;
在SML / NJ中，对每个语句进行类型检查，然后在现有类型环境中单独进行评估，然后再转到下一个语句。因此，所有代码在执行之前都会进行类型检查，但上述程序在失败之前仍会打印hello。但是，以下程序不会打印任何内容：
val foo : int = print "hello\n";
它不会打印你好然后尝试将nil存储到foo中。在此之前，它在单独的类型检查阶段失败。