Re: [Caml-list] Q: safe language

[John Max Skaller <skaller@ozemail.com.au>]

[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