Implicit Typing

ImplicitTyping is a term proposed on this Wiki for any language typing system which requires few or no type annotations (type declarations of variables, object members, function arguments, etc.) -- as opposed to ManifestTyping, in which type information must be provided by the programmer.

This comes in three flavours:

DynamicTyping. There are no explicit type annotations. Usually, typechecking occurs at runtime, causing an exception on type failures. Examples of such languages include LispLanguage, SmalltalkLanguage, PythonLanguage, RubyLanguage, and PhpLanguage.
Static TypeInference. Type annotations are optional. Typechecking occurs at CompileTime, and/or before the program is executed. Type failures cannot occur at runtime. Found in many functional languages, such as HaskellLanguage, MlLanguage, ObjectiveCaml.
SoftTyping. Type annotations are optional. Some types are inferred before the program is executed, but dynamic checks are inserted for any use of a value that cannot be statically inferred to be safe. Feedback is given to the programmer about which code is statically safe and which is not. Implemented in only a few languages: DrScheme, EeLanguage.

In addition, a language is StronglyTyped if it is either impossible for a type failure to occur at RunTime, or all type failures cause a well-defined error or exception. (There may be some "loopholes" in the checking of some constructs, but see StronglyTypedWithoutLoopholes.) It is WeaklyTyped if type failures are possible and cause UndefinedBehavior. This is in principle an orthogonal dimension to ManifestTyping vs ImplicitTyping. However, in practice very few languages are both weakly and implicitly typed (perhaps BcplLanguage?).

Note: In the above, "typechecking" refers to more than operations such as "instanceof" or "dynamic_cast" or similar. It refers to any query of an object to determine if it supports a given feature or property. Thus, a message send in SmalltalkLanguage involves typechecking, even though the concept of "types" is rather loose in Smalltalk. Likewise with a car/cdr operation in Lisp; both check to see that the operand is a ConsCell and not an atom; even though there is no real concept of an "atom" type. Think of typechecking as a "can I do this" operator.

Languages with ManifestTyping include CeeLanguage, CeePlusPlus, JavaLanguage, and CsharpLanguage.

DynamicTyping is far easier to implement than TypeInference, is a bit more flexible (there are many typing systems for which TypeInference is undecidable), and is more robust against changes in one module in a program consisting of multiple modules (the worst that can happen is DoesNotUnderstand, or a similar exception, being raised). However, it can be rather slow.

TypeInference has the advantage of lower runtime penalties (runtime typechecking costs machine cycles; many languages with TypeInference can elide most if not all typechecking code), and better provability (the compiler can prove that typing errors will not occur). However, in a large program with lots of different modules; assumptions built into the code can lead to UndefinedBehavior if one such module is replaced and the rest are not. (This is a problem with StaticTyping in general).

History retained for context:

Maybe AutomaticTyping is a better term for the union of TypeInference and DynamicTyping. ManifestTyping (the form of static typing found in languages like C/C++/Java, where type annotations have to be attached to every declaration) needs a good antonym; I prefer AutomaticTyping to the one currently suggested here on Wiki--LatentTyping. The term automatic suggests right up front why it's desirable--one less bookkeeping detail for the programmer to deal with.

I agree that it would be nice to have an antonym to ManifestTyping, and AutomaticTyping is probably better than anything else I've heard. It still doesn't feel quite right to me, though. "Automatic" makes it sound like Smalltalk is going to extra trouble behind the scenes to deal with types for you. It really isn't. It's just waiting until the type information is handy. There's a kind of simplicity there that the word "automatic" doesn't convey.

But this is a silly nit to pick, and I don't have a better suggestion. :) So go for it.

How about LazyTyping?

Or more seriously ImplicitTyping, which is expressive

verbally as matching TypeInference ("I infer what you imply"), and because something implicit can be made manifest
functionally in that it suggests that the data for potential TypeInference are present in unprocessed form.

Even in strongly typed languages there is partial implicit typing in situations such as:

  const X = 5;

In the above code, we do not declare X as a byte or an integer. It is implicitly decided by the compiler (or interpreter).

  const S = 'hello';

Above we do not declare S as a string or an array of chars. It is implicitly decided by the compiler (or interpreter).

Even in strongly typed languages... - ImplicitTyping/ManifestTyping is orthogonal to StrongTyping/WeakTyping. In strongly typed languages with full ImplicitTyping (such as ML and Haskell), there is a great deal more than 'partial' ImplicitTyping.However, since your point seems to be that some languages that primarily favor ManifestTyping possess some simple ImplicitTyping, you're right on that point - and, across versions, more such languages are receiving 'auto' typed variables, not just constants (including C++0X).

  auto v = some+hideous*expression;

Imagine though, if we had "no constants" or "implicit constant/variables". At some point, the human has to intervene and write down in the code a contract as to what is what - explicitely. Imagine if your language required you make assumptions about whether a variable is really a constant or not? Doesn't sound logical? Imagine a language without any constants - it was up to you to make sure a variable stayed constant or not - because it was implicit. A variable staying constant? Huh? Yes, this ridiculousness happens. If I want a string to stay a string - it is not necesarily possible in dynamically typed languages if there is no explicit human written contract! One should be able to declare whether or not his type stays a "constant type of type" - just as one can declare whether his variable can remain constant or not (yes, I realize the irony - a variable that is a constant is not a variable - but see my point?). See also TypeSystemThroughComments for more thoughts on sterility of code.

There are many languages without constant identifiers, so they're easy to imagine - even languages where you can change the value of 'pi'. But I do prefer languages support declaration and proof of invariants - i.e. they support it so I don't have to guarantee it by hand. (In a one-man project of smaller size, invariants ain't a big deal... it's when you have teams of five or six or more people, and you're rotating interns, etc. that you want invariants to resist the WorseThanFailure approaches to programming.)

I find some problems with this description/category. First, we should distinguish between "not required" and "not allowed".

Second, there are often implied ways to supply type info to the interpreter/compiler (I/C). For example, even if there are no formal type declarations, the existence of quotes around a constant (string) or decimals (float) could potentially be a kind of type declaration (if the I/C chooses to use such info). I've worked with languages like this. Rough example:

  a = 23;
  b = "23";
  c = 23.0;
  print(type(a)); // result: INTEGER
  print(type(b)); // result: STRING
  print(type(c)); // result: DOUBLE

I'm not sure "implied" is the right word. If the "rules" are that "quotes mean string", then using quotes is no different than an explicit type indicator. The difference is a matter of syntax, not semantics. Quotes are no more or less "implied" than the prefix "String". These two may generate identical machine language (depending on language):

  double x = 0;

  var x = 0.0;// period implies "double"

Third, declarations may not mean much. For example, if you declare everything Variant in VB or Object in Java, you are still making a type declaration. But they are not usable declarations in a "type" sense. This is essentially emulating a type-free language (assuming a sufficient number of operators will process "variants"). --top

Does this set of categories cover old FortranLanguage's implicit typing? Would Fortran code sans explicitly typed variables be considered Static TypeInference?

CategoryLanguageTyping