From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA10732; Sun, 1 Sep 2002 10:09:05 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA10565 for ; Sun, 1 Sep 2002 10:09:04 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g8187JD18881 for ; Sun, 1 Sep 2002 10:07:31 +0200 (MET DST) Received: from ozemail.com.au (syd-ts16-2600-111.tpgi.com.au [203.213.84.111]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id g8187Cu05216 for ; Sun, 1 Sep 2002 18:07:12 +1000 Message-ID: <3D71CAAF.8060509@ozemail.com.au> Date: Sun, 01 Sep 2002 18:07:11 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Caml-list Subject: Re: [Caml-list] Q: safe language References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [long post ...] J Farrand wrote: > On Fri, 30 Aug 2002, Vitaly Lugovsky wrote: > > >> No. In this place program may be expecting some structure, which can >>contain NIL. There is no other way in lisp to define structures - so, any >>code accepting lists will accept any alien structure. Is is type safety? >>No way! Dynamically typed languages can't be safe. >> > > "Safe" is not the same as "Type Safe". ISTR safe means that a program > written in the language will not cause a machine level error. It's a dubious distinction. I don't agree. Safe could mean "guarranteed to be correct at compile time". Since there certainly is no way to specify intended semantics in any language, since even such a specification could be wrong, "safe" as I just specified is a formally meaningless term. > So for > example, C is not safe because you can derefence a bad pointer etc. and > cause a seg fault. That's wrong. There is no such requirement in the ISO C Standard. Indeed, instrumented versions of C check for null pointer dereferences. Some may do so with code inserted at each dereference, and some by trapping hardware exceptions. Solaris "Purify" is such an instrumenting program. > LISP is safe. Even though you can apply a function to > arguments of the wrong type, LISP has well defined behaviour for dealing > with this. Well definedness isn't enough either. Many things in C are not "well defined", but they're not unsafe either. The actions of a C language translator may have one outcome (deterministic), one of several (which is called "unspecified behaviour" in ISO C++), anything the implementor defined ("implementation specified" in C++), or any behaviour at all ("undefined behaviour" in C++). It's not clear what "well defined" means, when one simply says that the behaviour of any program is one of a set of behaviours, possibly a singleton (deterministic) or possibly the universal set ("undefined") -- that makes the behaviour "well defined" in all cases! Even a syntax error has well defined behaviour-- the translator is required to reject the program and issue a diagnostic error message. Note that the distinction between compile time and run time doesn't exist for C or C++ (to allow interpreters to be legitimate implementations), so you can't start talking about "run time" failures. Clearly, the Ocaml bytecode interpreter in interactive mode is an interpreter too. Of course, there is an urban myth that some languages are "safe" and others are not. Ocaml, unfortunately, contributes to this misleading idea by claiming to be a "safe" language. It isn't. It can core dump. It can throw exceptions. It doesn't guarrantee correctness. It contains non-deterministic semantics whose behaviour sets are restricted but not singleton (such as bit operations on ints). Perhaps you can say that Ocaml programs cannot have a certain class of errors such as null pointer dereferences, though that really an ill-formed claim, since it doesn't have pointers :-) A more important claim is that the type system is sound, while that of, say, C++, is not. That is a proposition of a formal mathematical system, although the formal model of the typing of each language is not given precisely (either in the C or C++ Standards, or in the Ocaml reference). Still, this kind of claim has more weight in my mind, than saying Ocaml is 'safer' than C simply because it traps some addressing exceptions. In my opinion, it is more useful to ask users of multiple languages "in which language do you feel that for a given budget and resources you can deploy a program and expect the smallest maintenance costs?". Now there, without hesitation, I'd place Ocaml well above C++ for a considerable class of applications, particularly the kind I like to develop :-) I think the question is a good start, because with some thought and assumptions one might even *quantify* the answer: such a metric would be problematic, but its existence might start to give some credence to the intended notion: that Ocaml is a better language because it is cheaper to develop a robust application with a given semantic/performance goal, for a significant range of application types. This is actually a Frequently Asked Question: "Is Ocaml good for numerical programming? Game programming?" so I think that it may be a sensible measure of quality. More abstractly, we ask: "What formal properties are correlated with quality programming languages?" with answers like "sound type system" and "garbage collection" and "referential transparency" all being accepted indicators. And one that should be popular on this list "Strong emphasis on functional programming style" :-) --- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners