强类型,弱类型,动态,静态

本文非原创,是下列一系列文章的集合,帮助理解。

Answer 1

https://www.zhihu.com/question/19918532/answer/21647195

类型系统的一些概念,众说纷纭,使用上也比较乱。有些东西,甚至不好严格定义。以下算学术界的一种相对“严格”的说法。

1. 先定义一些基础概念

Program Errors

  • trapped errors。导致程序终止执行,如除0,Java中数组越界访问
  • untrapped errors。 出错后继续执行,但可能出现任意行为。如C里的缓冲区溢出、Jump到错误地址

Forbidden Behaviours
语言设计时,可以定义一组forbidden behaviors. 它必须包括所有untrapped errors, 但可能包含trapped errors.

Well behaved、ill behaved

  • well behaved: 如果程序执行不可能出现forbidden behaviors, 则为well behaved。
  • ill behaved: 否则为ill behaved...
2. 有了上面的概念,再讨论强、弱类型,静态、动态类型

强、弱类型

  • 强类型strongly typed: 如果一种语言的所有程序都是well behaved——即不可能出现forbidden behaviors,则该语言为strongly typed。
  • 弱类型weakly typed: 否则为weakly typed。比如C语言的缓冲区溢出,属于trapped errors,即属于forbidden behaviors..故C是弱类型

前面的人也说了,弱类型语言,类型检查更不严格,如偏向于容忍隐式类型转换。譬如说C语言的int可以变成double。 这样的结果是:容易产生forbidden behaviours,所以是弱类型的

动态、静态类型

  • 静态类型 statically: 如果在编译时拒绝ill behaved程序,则是statically typed;
  • 动态类型dynamiclly: 如果在运行时拒绝ill behaviors, 则是dynamiclly typed。
3. 误区

大家觉得C语言要写int a, int b之类的,Python不用写(可以直接写a, b),所以C是静态,Python是动态。这么理解是不够准确的。譬如Ocaml是静态类型的,但是也可以不用明确地写出来。。Ocaml是静态隐式类型

静态类型可以分为两种:

  • 如果类型是语言语法的一部分,在是explicitly typed显式类型;
  • 如果类型通过编译时推导,是implicity typed隐式类型, 比如ML和Haskell
4.下面是些例子

无类型: 汇编
弱类型、静态类型 : C/C++
弱类型、动态类型检查: Perl/PHP
强类型、静态类型检查 :Java/C#
强类型、动态类型检查 :Python, Scheme
静态显式类型 :Java/C
静态隐式类型 :Ocaml, Haskell

===============

Answer 2

https://www.zhihu.com/question/19918532/answer/47112288

前面 @姚培森 给的定义比较详细,但我觉得并不易于理解,而且我看到评论里已经有人产生了一些误解。我的理解是,这些概念本身就只是一种通俗的说法,并没有严格的定义,只能勉强用一些术语来厘清边界。下面是《Programming Language:Application and Interpretation》里给的一种解释,我觉得更易于理解:
ee19ac87e0b6adc9812c2e2cf77e7dc3_1440w
从图上看,静态类型、动态类型大家应该明白其实是指的Type Check发生的时机。而强类型、弱类型到底是什么意思呢?其实这些词语本身概念就是模糊不清的,反正我是能避免使用就尽量避免使用。So what is “strong typing”?

This appears to be a meaningless phrase, and people often use it in a non-sensical fashion. To some it seems to mean “The language has a type checker”. To others it means “The language is sound” (that is, the type checker and run-time system are related). To most, it seems to justmean, “A language like Pascal, C or Java, related in a way I can’t quite make precise”. If someone uses thisphrase, be sure to ask them to define it for you. (For amusement, watch them squirm.)

@刘典 在 @姚培森 的回答下面提了一个疑问,我理了一下这个逻辑:

  • 按照定义,如果在编译时拒绝ill behaved程序,则是statically typed。
  • 按照定义,如果一种语言的所有程序都是well behaved,则该语言为strongly typed。
  • 那么,所有statically typed语言都是well behaved,即strongly typed。

这逻辑错在哪里呢?问题在于:在编译时拒绝(部分)ill behaved是编译器的行为,并不是概念上的定义。事实上,问题正出在 「Statically Typed」这个词身上!

可以这么说,并不存在 Statically Typed,只有 Statically Checked。
http://lucacardelli.name/papers/typesystems.pdf

In general, we avoid the words type and typing when referring to run time concepts; for example we replace dynamic typing with dynamic checking and avoid common but ambiguous terms such as strong typing.

因为它不是语言固有属性,而是编译器的行为,搞清这点就不会产生误解了。可能有人会问,既然Statically Typed 不是语言固有属性,那C\C++、Java的类型声明又怎么解释呢?前面说了,那叫「Explicitly Typed」,类型是语言语法的一部分,但到底是静态检查还是运行期检查,或者是根本不检查,那就是编译器解释器的行为了。比如PHP有Type Hint,看上去就像 Explicitly Typed,但它是运行到那行代码才检查,仍然不是Statically Checked。好了,现在静态类型动态类型算是搞清楚了吧。

那 Type Safety 呢?

Type safety is the property that no primitive operation ever applies to values of the wrong type. By primitive operation we mean not only addition and so forth, but also procedure application. A safe language honors the abstraction boundaries it erects.

这也算是通俗的解释了,符合大众印象,大家所理解的强类型、类型安全等,通常都是指运算符和函数调用,比如将原本作用于Int的“*”去用到字符串上是不合法的,程序不会继续往下执行。

为什么C/C++ 是Type unsafe呢?注意,type是和value绑定到一起的,所以:

int a = 4;
char* s = (char*)a; //假设类型转换OK通过编译
void f(char* s);
f(s); // unsafe

C/C++ 本不具备一个 Sound Type System,即它的类型系统本身就并不能保证安全。

为什么大家认为Python是强类型呢?也就是说他们倾向于认为Python是类型安全的?CPython解释器就是Python语言事实上的标准,所以我们就直接看Python解释器的行为了,它会在运行期检测类型错误,程序会中断执行:

class A:
  def halo(self):
    print "A"

class B: 
  pass

A.halo(B()) # 抛出 TypeError,如果B继承自A则不会报错

当然,ctypes这种东西我们就不考虑了。相比之下,JavaScript就很明显谈不上类型安全,但这也取决于你的定义,如果你将类型安全的定义放宽,也可以认为 JavaScript 类型安全,比如调用不存在的方法 JS 也会中断执行。

Subscribe to 隅

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe