🚀 go-pugleaf

In article  <2837@enea.se> Erland Sommarskog writes:
]
]So when the types don't match, you crash. Sure, this is well-
]defined, but in many application it is just as unacceptable
]as undefined behaviour.

First of all, this "crash" cannot do arbitrary things like overwrite
files.  Second, it may not necessarily crash, there are other things
that can happen, depending on the languages exception-handling
facilities.  Third, there are very few applications where a crash is
as bad as undefined behavior.  Undefined behavior can do all kinds of
nasty things to the system.  For example, referencing past the end of
an array in C causes undefined behavior:

void trouble()
{ int arr[4]
  int delete_flag = 0;

  ...
  arr[4] = 1;  /* undefined behavior -- might set delete_flag to 1 */
  ...
  if (delete_flag) delete_all_files();
  ...
}

This is much worse than what you get with dynamically typed languages.
The only place where an error stop can be this bad is in critical
real-time applications, and such applications should have exception
handling to avoid error stops.

]If variables never can be uninitiated in your dynamicly typed 
]language, I guess their behaviour can be well-defined.

I can't think of any dynamically typed language where the use of an
unitialized variable causes undefine behavior, but there surely are
some.  I can think of several statically typed languages where it
causes undefined behavior.  In any case, undefined variable semantics
is orthogonal to typing.  I have no objection to compilers that issue
errors for undefined variables in any language.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman