# Is the choice of static and dynamic typing not visible to the programmers of the languages? [closed]

From Design Concepts in Programming Languages by Turbak

Although some dynamically typed languages have simple type markers (e.g., Perl variable names begin with a character that indicates the type of value: \$ for scalar values, @ for array values, and % for hash values (key/value pairs)), dynamically typed languages typically have no explicit type annotations.

The converse is true in statically typed languages, where explicit type annotations are the norm. Most languages descended from Algol 68 , such as Ada , C / C++ , Java , and Pascal , require that types be explicitly declared for all variables, all data-structure components, and all function/procedure/method parameters and return values. However, some languages (e.g., ML , Haskell , FX , Miranda ) achieve static typing without explicit type declarations via a technique called type reconstruction or type inference.

Question 1: For dynamically typed languages which "have no explicit type annotations", do they need to infer/reconstruct the types/classes, by using some type/class reconstruction or type/class inference techniques, as statically typed languages do?

Question 2: The above quote says static or dynamic typing and explicit or no type annotations can mix and match.

• Is the choice between static and dynamic typing only internal to the implementations of programming languages, not visible to the programmers of the languages?

• Do programmers in programming languages only notice whether the languages use explicit type/class annotations or not, not whether the languages use static or dynamic typing? Specifically, do languages with explicit type/class annotations look the same to programmers, regardless of whether they are static or dynamic typing? Do languages without explicit type/class annotations look the same to programmers, regardless of whether they are static or dynamic typing?

Question 3: If you can understand the following quote from Practical Foundation of Programming Languages by Harper (a preview version is https://www.cs.cmu.edu/~rwh/pfpl/2nded.pdf),

• Do the syntax for numeral (abstract syntax num[n] or concrete syntax overline{n}) and abstraction (abstract syntax fun(x.d) or concrete syntax λ(x)d ) use explicit types/classes with dynamic typing?
• If yes, is the purpose of using explicit types/classes to avoid type inference/reconstruction?

Section 22.1 Dynamically Typed PCF

To illustrate dynamic typing, we formulate a dynamically typed version of PCF, called DPCF. The abstract syntax of DPCF is given by the following grammar:

Exp d :: = x x variable
num[n] overline{n}      numeral
zero zero      zero
succ(d) succ(d)      successor
ifz {d0; x.d1} (d) ifz d {zero → d0 | succ(x) → d1}      zero test
fun(x.d) λ(x)d      abstraction
ap(d1; d2) d1 (d2)      application
fix(x.d) fix x is d      recursion


There are two classes of values in DPCF, the numbers, which have the form num[n], and the functions, which have the form fun(x.d). The expressions zero and succ(d) are not themselves values, but rather are constructors that evaluate to values. General recursion is deﬁnable using a ﬁxed point combinator but is taken as primitive here to simplify the analysis of the dynamics in Section 22.3.

As usual, the abstract syntax of DPCF is what matters, but we use the concrete syntax to improve readability. However, notational conveniences can obscure important details, such as the tagging of values with their class and the checking of these tags at run-time. For example, the concrete syntax for a number, overline{n}, suggests a “bare” representation, the abstract syntax reveals that the number is labeled with the class num to distinguish it from a function. Correspondingly, the concrete syntax for a function is λ (x) d, but its abstract syntax, fun(x.d), shows that it also sports a class label. The class labels are required to ensure safety by run-time checking, and must not be overlooked when comparing static with dynamic languages.

Thanks.

• The usual rule is one question per post. – Yuval Filmus Oct 30 '19 at 15:26
• Are you familiar with RTTI and duck typing? – Yuval Filmus Oct 30 '19 at 15:26
• Please remove all but one question from your post. You seem to be asking at least four very different ones. Keep in mind that argumentative, open-ended "discussion starters" are unsuited for this platform (as you should be well aware, you've been around for a while). – Raphael Oct 30 '19 at 21:07

Question 1

No, dynamically-typed programming languages usually do not perform any kind of type inference. The common approach is to check types at runtime, and cause a runtime error or exception in case a type mismatch is found.

Question 2

Having static or dynamic type checking is a choice which is visible to programmers. A program like

print "hello"
print (3 / "a string?")


in a statically-typed language will cause a compile-time type error (hence before it prints anything), while in a dynamic language the program will start, print hello, and then error out.

Also a program like

if 0==1:
print (3 / "a string?")


will run perfectly fine in a dynamically-typed language, but won't compile if using static type checking.

Question 3

There is no type inference, or type reconstruction being performed there. Types are not made explicit in the program. The runtime system can simply store a tag near values to remember their type (number or function), so that runtime type checking can be performed.