Newsgroups: comp.lang.misc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!olson From: olson@juliet.ll.mit.edu ( Steve Olson) Subject: Machine Language Typing (Was Re: A Hard Problem for Static Type Systems) In-Reply-To: stephen@estragon.uchicago.edu's message of 3 May 91 11:12:50 GMT Message-ID: Lines: 41 Sender: usenet@xn.ll.mit.edu Organization: M.I.T. Lincoln Lab - Group 43 References: <2392@optima.cs.arizona.edu> <3156@opal.cs.tu-berlin.de> <51984@nigel.ee.udel.edu> Date: 3 May 91 12:40:40 In article stephen@estragon.uchicago.edu (Stephen P Spackman) writes: I have to disagree. A good machine language (one with no Catch Fire & Burn instructions) for a machine without programmer-visible caching is both strongly and statically typed, simply by virtue of the fact that all consequences of a given machine state are defined. You are making the mistake of imagining that addresses and ints and so forth exist in object code; but they don't. Those are abstractions in your mind. Ultimately they are NOT represented in the machine model. Bits go here, bits go there, the memory holds bits and nothing else. The (only) data type is the bit.... If one puts an integer into a floating point instruction, one might get a deteriminstic result. But so what? The result wouldn't be meaningful. I might as well argue the only real data type is the voltage level. I'm really not trying to be silly here. The fact that machines are strongly typed underlyingly is the thing that makes secure implementations possible. If something could happen to be in memory that wasn't a bit, no language layered above could ever have guaranteed behaviour... (which is why it's bad when the hardware fails - untrapped type violations then CAN occur.... :-). It's sensible to ask, then, how we can implement UNTYPED langauges on top of this typed substrate. My guess is it's because memory is finite.... Which is to say, it's done with smoke & mirrors. According to your definitions a weakly typed language is impossible on deterministic hardware. Depending on how you set up your starting definitions, there might be some narrow, literal truth to it, but it dosen't seem like a terribly useful way to think about programming languages. ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies systems analyst University of Chicago ---------------------------------------------------------------------- -- -- Steve Olson -- MIT Lincoln Laboratory -- olson@juliet.ll.mit.edu --