Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

PL theorists - from what I saw, not being one - prefer the term "unityped". It's not true that there are no (static!) types - there is a single, unnamed type which contains all possible values.


PL theorists who know what they are talking about know that this is false, because the actual diverse types of those values can be reasoned about at compile time. Such a "unityped" program is made up of syntax. We can reason about an expression more deeply than just "it returns a value" and we can do so statically. For instance in Lisp we know more about an expression like (cons 1 2) than that it returns a value. We know statically that it returns a cons. From that we can infer that (+ (cons 1 2) 3) is not well-typed.

Type isn't just an implementation system; it's how we can reason about the program, as a mathematical object. The reasoning which informs us that (+ (cons 1 2) 3) is not well-formed without evaluating it, has to do with type.

How we implement values (using a generic "cell" that is type-tagged) is just a convenience. We can get things working without being concerned for up-front type checking. It also represents the philosophy that type is innate to objects (not just a syntactic property of programs).

A piece of compiled code can have a type passed into it which didn't exist when that code was compiled, and sensible things can happen anyway.


It's not false, it's just unspecified. If you hand me scheme I can provide it a unitype system without conflict. If you hand me Haskell I cannot because the language has explicitly said that uncheckable statements are invalid.

You can of course go further with your static analysis—a language may support many type systems in principle regardless of what the compiler accepts.


It depends on the context. I guess rayiner has referred to "untyped lambda calculus".

Thats not a bad name as it is self consistent - there are no type expressions in that language. If you say that it is actally "unityped" it is (just) your (semantical) categorization looking at it from a higher level perspective.

Of course on the other side whole numbers were just "number"-s, before fractionals came, so in the end it may be ok to introduce higher level perspective in naming just to diferrentiate better. :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: