Subject: Re: Newbie questions From: Erik Naggum <erik@naggum.no> Date: 1999/05/04 Newsgroups: comp.ai,comp.lang.lisp Message-ID: <3134844303370291@naggum.no> * Bagheera, the jungle scout <bagherra@my-dejanews.com> | I think what josh is getting at is that in C++, it prevents you from | stuffing an 8byte value into a two byte parameter. If you don't have | type checking for this sort of thing, you can easily overflow your | calling stack, which is a bad no-no. Basically it is a matter of the | program protecting itself from the programmer. this is not what static types are about. having static types _allows_ a compiler to skimp on (some) run-time type checking in the belief that all or most of the necessary type checking can be performed compile-time. this is, of course, as ridiculous a desire as wanting the compiler to prove the program free of any other bug, and has confused people to no end about what types are. the important property of static types is not what would happen if you took it away, but what happens when you introduce it: you can take away some fences that you presume the compiler took care of, but the only actual consequence is that you leave open the whole area of precisely the kind of bugs you mistakenly associate with languages and compilers with dynamic types. even in the machine language, there are types and associated operations on them. some of the types may look very much the same when stored as bits in machine memory, but that is really an artifact of a context-dropping human viewer -- the archetypical example is the C notion of a pointer and its interchangeability with integers of some size. the stored pointer doesn't become an integer any more than a parked car becomes a source of money when broken into by a thief -- in both cases, it's how you use it that matters, and we have laws and regulations that say that parked cars are just that and not sources of money. if you willfully transgress these laws, you can turn a parked car into a source of money, but most people know they're doing something wrong when they do this, and even the lowliest thief who knows this is morally superior to the C programmer who abuses the bits of a pointer as an integer and takes it for granted. any form of representation is subject to interpretation by a conscious mind that imputes meaning to the inherently meaningless. if, however, you partition the otherwise confusing representation space into various categories and make certain that you know which category something is of even at run-time, you don't get into the kinds of silly troubles that C/C++ fans think static typing got them out of: they never happen in the first place. or, to be more precise, any powerful system will allow you to break the rules, but it has to be on purpose, not by silly mistake, which is, unfortunately, what C/C++ give you absent static type checks. so, "if you don't have type checking for this sort of thing", you move that type checking into the run-time, instead, and you _can't_ overflow your calling stack. I'd argue that _dynamic_ typing is how a program protects itself from the programmer, and static typing that makes a whole lot of errors and problems _arise_. | I'm sure there are lots of ways to shoot yourself in the foot with Lisp. how did you acquire your certainty about this who know nothing about what to do if you don't do static typing? (hint: if you want to destroy the world through Lisp, you have to work hard at it. if you want to destroy the world through C/C++, simply derefence a stray pointer or _forget_ to check for NULL, which is _manual_ run-time type checking.) | C++ is a concerted effort to reduce that possibility of self-destruction. it must be Slobodan Milosovic's favorite programming language, then. | True, Lisp gives you the option of run-time program correction... but | sometimes requirements don't allow that comfort. you know, I'm a little irritated by the ignorant newbies who come here and on other lists and aske all sorts of inane questions, but it beats having to deal with ignorants who think they now enough to make blanket statements. #:Erik