为什么解释的语言大多是鸭式的,而编译的语言有强类型? [英] Why interpreted langs are mostly ducktyped while compiled have strong typing?

查看:18
本文介绍了为什么解释的语言大多是鸭式的,而编译的语言有强类型?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我只是不知道,这有什么技术原因吗?为弱类型的语言实现编译器是否更难?这是什么?

I just don't know that, is there any technical reason for that? Is it more difficult to implement a compiler for a language with weak typing? What is it?

推荐答案

问题背后的前提有点狡猾.解释语言大多是鸭式的,这是不正确的.编译语言大多具有强类型是不正确的.类型系统是一种语言的属性.编译与解释是实现的属性.

The premises behind the question are a bit dodgy. It is not true that interpreted languages are mostly ducktyped. It is not true that compiled languages mostly have strong typing. The type system is a property of a language. Compiled versus interpreted is a property of an implementation.

例子:

  • Scheme 是动态类型的编程语言(又名鸭子类型),它有许多解释实现,但也有一些优秀的本地代码编译器,包括 Larceny、Gambit 和 PLT Scheme(其中包括 解释器和 JIT 编译器进行无缝转换).

  • The programming language Scheme is dynamically typed (aka duck-typed), and it has many dozens of interpreted implementations, but also some fine native-code compilers including Larceny, Gambit, and PLT Scheme (which includes both an interpreter and a JIT compiler making seamless transitions).

编程语言 Haskell 是静态类型的;两个最著名的实现是解释器 HUGS 和编译器 GHC.还有其他几个值得尊敬的实现在编译为本机代码 (yhc) 和解释 (Helium) 之间平均分配.

The programming language Haskell is statically typed; the two most famous implementations are the interpreter HUGS and the compiler GHC. There are several other honorable implementations split about evenly between compiling to native code (yhc) and interpretation (Helium).

标准 ML 编程语言是静态类型的,它有许多本机代码编译器,其中最好和最积极维护的编译器之一是 MLton,但最有用的实现之一是解释器 Moscow ML

The programming language Standard ML is statically typed, and it has had many native-code compilers, of which one of the best and most actively maintained is MLton, but one of the most useful implementations is the interpreter Moscow ML

Objective Caml 编程语言是静态类型的.它只有一个实现(来自法国的 INRIA),但这个实现包括两个一个解释器和一个本机代码编译器.

The programming language Objective Caml is statically typed. It comes with only one implementation (from INRIA in France) but this implementation includes both an interpreter and a native-code compiler.

编程语言 Pascal 是静态类型的,但它在 1970 年代开始流行,因为 UCSD 构建了基于 P 代码解释器的出色实现.在后来的几年中,可以使用精细的本机代码编译器,例如用于 370 系列计算机的 IBM Pascal/VS 编译器.

The programming language Pascal is statically typed, but it became popular in the 1970s because of the excellent implementation built at UCSD, which was based on a P-code interpreter. In later years fine native-code compilers became available, such as the IBM Pascal/VS compiler for the 370 series of computers.

编程语言 C 是静态类型的,今天几乎所有的实现都是编译的,但在 1980 年代,我们这些有幸使用 Sabre C 的人正在使用解释器.

The programming language C is statically typed, and today almost all implementations are compiled, but in the 1980s those of us lucky enough to be using Saber C were using an interpreter.

尽管如此你的问题背后有一些道理,所以你应该得到一个更深思熟虑的答案.事实上,动态类型语言似乎确实与解释型实现相关.为什么会这样?

Nevertheless there is some truth behind your question, so you deserve a more thoughtful answer. The truth is that dynamically typed languages do seem to be correlated with interpreted implementations. Why might that be?

  • 许多新语言都是由实现定义的.构建解释器比构建编译器更容易.动态检查类型比静态检查更容易.而且,如果您正在编写解释器,则静态类型检查几乎没有性能优势.

  • Many new languages are defined by an implementation. It is easier to build an interpreter than to build a compiler. It is easier to check types dynamically than to check them statically. And if you are writing an interpreter, there is little performance benefit to static type-checking.

除非您正在创建或调整一个非常灵活的多态类型系统,否则静态类型系统可能会妨碍程序员.但是,如果您正在编写解释器,一个原因可能是创建一个小型、轻量级的实现,让程序员远离.

Unless you are creating or adapting a very flexible polymorphic type system, a static type system is likely to get in the programmer's way. But if you are writing an interpreter, one reason may be to create a small, lightweight implementation that stays out of the programmer's way.

在某些解释型语言中,许多基本操作非常昂贵,因此在运行时检查类型的额外开销并不重要. PostScript 就是一个很好的例子:如果你要要立即运行并栅格化贝塞尔曲线,您不会犹豫在这里或那里检查类型标签.

In some interpreted languages, many fundamental operations are so expensive that the additional overhead of checking types at run time doesn't matter. A good example is PostScript: if you're going to run off and rasterize Bezier curves at the drop of a hat, you won't balk at checking a type tag here or there.

顺便说一下,请注意强"和弱"打字这两个术语,因为它们没有普遍认可的技术含义.相比之下,静态类型意味着程序在执行之前会被检查,并且程序可能会在启动之前被拒绝.动态类型表示的类型在执行过程中被检查,错误类型的操作可能会导致程序停止或以其他方式在运行时发出错误信号.静态类型的一个主要原因是排除可能有这种动态类型错误"的程序.(这是编写解释器的人通常对静态类型不太感兴趣的另一个原因;执行在类型检查之后立即发生,因此保证的区别和性质不那么明显.)

Incidentally, please be wary of the terms "strong" and "weak" typing, because they don't have a universally agreed technical meaning. By contrast, static typing means that programs are checked before being executed, and a program might be rejected before it starts. Dynamic typing means that the types of values are checked during execution, and a poorly typed operation might cause the program to halt or otherwise signal an error at run time. A primary reason for static typing is to rule out programs that might have such "dynamic type errors". (This is another reason people who write interpreters are often less interested in static typing; execution happens immediately after type checking, so the distinction and the nature of the guarantee aren't as obvious.)

强类型一般表示类型系统没有漏洞,而弱类型表示类型系统可以被颠覆(失效任何保证).这些术语经常被错误地用于表示静态和动态类型.要看到区别,想想 C:该语言在编译时进行类型检查(静态类型),但有很多漏洞;您几乎可以将任何类型的值转换为相同大小的另一种类型——特别是,您可以自由地转换指针类型.Pascal 是一种旨在进行强类型化的语言,但有一个众所周知的无法预见的漏洞:没有标签的变体记录.

Strong typing generally means that there are no loopholes in the type system, whereas weak typing means the type system can be subverted (invalidating any guarantees). The terms are often used incorrectly to mean static and dynamic typing. To see the difference, think of C: the language is type-checked at compile time (static typing), but there are plenty of loopholes; you can pretty much cast a value of any type to another type of the same size---in particular, you can cast pointer types freely. Pascal was a language that was intended to be strongly typed but famously had an unforeseen loophole: a variant record with no tag.

随着时间的推移,强类型语言的实现经常会出现漏洞,通常使得运行时系统的一部分可以用高级语言实现.例如,Objective Caml 有一个名为 Obj.magic 的函数,它具有简单地返回其参数的运行时效果,但在编译时它将任何类型的值转换为任何其他类型的值.我最喜欢的例子是 Modula-3,其设计者将他们的类型转换构造称为 LOOPHOLE.

Implementations of strongly typed languages often acquire loopholes over time, usually so that part of the run-time system can be implemented in the high-level language. For example, Objective Caml has a function called Obj.magic which has the run-time effect of simply returning its argument, but at compile time it converts a value of any type to one of any other type. My favorite example is Modula-3, whose designers called their type-casting construct LOOPHOLE.

总结:

  • 静态与动态是语言.

编译 vs 解释是实现.

原则上这两个选择可以并且是正交的,但出于合理的技术原因动态类型经常与解释相关.

In principle the two choices can be and are made orthogonally, but for sound technical reasons dynamic typing frequently correlates with interpretation.

这篇关于为什么解释的语言大多是鸭式的,而编译的语言有强类型?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆