Xref: utzoo comp.lang.misc:7193 comp.object:2975 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!agate!stanford.edu!neon.Stanford.EDU!hoelzle From: hoelzle@neon.Stanford.EDU (Urs Hoelzle) Newsgroups: comp.lang.misc,comp.object Subject: Re: CHALLENGE: typing and reusability Message-ID: <1991Mar31.214826.18402@neon.Stanford.EDU> Date: 31 Mar 91 21:48:26 GMT References: <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu> <19MAR91.22493670@uc780.umd.edu> <18271:Mar2013:19:1091@kramden.acf.nyu.edu> <1991Mar20.214231.3411@neon.Stanford.EDU> <1121@tetrauk.UUCP> Organization: Computer Science Department, Stanford University, Ca , USA Lines: 26 rick@tetrauk.UUCP (Rick Jones) writes: >The real issue is not that the solution can't be type-checked, it's that the >problem itself doesn't type-check. This is not true - unless we have different understandings of what "type-check" means. For me, a program "type-checks" statically (is type-safe) iff you can prove, from the text of the program alone, that no "message not understood" errors will occur at run-time, i.e. that no interfaces are violated. As explained in an earlier posting, the example *does* type-check in this sense. >Please note that I'm not flaming dynamic typing as a concept, it has many >points in its favour. What I would say is that any well-engineered design >should in principle be statically type checkable, even if you choose to >implement it in a dynamically typed language. I agree with you 100%. My point is that today's type systems disallow many legal (type-safe) programs because they are just too restricted (the type systems, not the programs ;-). -Urs -- ------------------------------------------------------------------------------ Urs Hoelzle hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305