Go to the first, previous, next, last section, table of contents.

Objects Have Types, Variables Don't

If I use my finger as a pointer, I can use it to point to all kinds of things--a computer, a painting, a motorcycle, or any number of things. Variables in Scheme are like this, too.

Dynamic typing

In Scheme, all variables have the same type: "pointer to anything."

Scheme is dynamically typed, meaning that variables don't have fixed types, but objects do. An object carries its type around with it--an integer is an integer forever, but a variable may refer to an integer at some times, and a string (or something else) at other times. The language provides type-checking at run time to ensure that you don't perform the wrong operations on objects--if you attempt to add two strings, for example, the system will detect the error and notify you.

Sometimes, people refer to languages like Scheme (and Lisp and Smalltalk) as untyped. This is very misleading. In a truly untyped language (like FORTH and most assembly languages), you can interpret a value any way you want--as an integer, a pointer, or whatever. (You can also do this in C, using unsafe casts, which is a source of many time-consuming bugs.(3) )

In dynamically typed systems, types are enforced at runtime. If you try to use the numeric procedure + to add two lists together, for example, the system will detect the error and halt gracefully--it won't blithely assume you know what you're doing and corrupt your data. You also can't misinterpret a nonpointer value as a pointer, and generate fatal segmentation violations that kill your program.

You might think that dynamic typing is expensive, and it can be. But good Scheme compilers can remove most of the overhead by inference at compile time, and most advanced implementations also let you declare types in performance-critical places so that the compiler can generate code similar to that for C or Pascal.

[ I've left out some text from my course notes about tagging and immediate values (more detailed)... put back in, maybe in an appendix ]

This is the end of Hunk C


At this point, you should go read Hunk D of the next chapter
and work through the examples using a running Scheme system.
Then return here and resume this chapter.

(Go to Hunk D, which starts at section Making Some Objects (Hunk D).)

Go to the first, previous, next, last section, table of contents.