Christopher Smith wrote:
Darren New wrote:
ensures all the right resources are cleaned up
With a sufficiently introspective language, it's easy to get
everything cleaned up.
I'd agree with you were it an *expected* error, but for unexpected
errors, this is not the case. By definition, you don't know what the
problem is, nor what the impact is, so you can't trust that say
introspection works correctly.
Um, well, sure you do. If I get a division by zero error, I'm pretty
sure my introspection is still going to work. If I get a syntax error,
or a null pointer exception, I'm also pretty sure my introspection will
still work. If you try to open a file that doesn't exist, and you forgot
to handle that failure, I'm pretty sure your introspection will still
work. If you run off the end of an array in Java or Tcl, you won't
corrupt things to the point where your introspection fails.
> Basically, nothing about the process' state is certain or trustworthy.
Um, why would you say that? That's kind of the difference between a safe
and unsafe language.
Now, of course, there can be bugs in the implementation of any language,
or hardware failures you can't detect. But we're talking languages here.
I guess it depends on what you mean by a "safe" language. I presumed you
meant a language that provides some degree of correctness checking of
your source code.
Ah. No. You don't know what a "safe" language is. It actually has
nothing to do with the correctness of your source code.
"Safe" is a technical term (in the same sense that "strongly typed" is a
different technical term) that means all executions of strings that
match the language definition are well-defined. C et al is "unsafe"
because there are operation (like running off an array) that cause
undefined behavior. Java is "safe" because everything you do has a
well-defined behavior.
One of the problems of talking about "safe" languages is that it can
become confusing to define what you mean by an "error". If trying to
dispatch a message to a null pointer is defined to (for example) send
the message and its arguments to an "unknown" handler, is it really an
"error" to use a null pointer? If running off an array reliably
generates an "out of bounds index" exception, is running off the end of
an array really an error? Usually, yes, but if you put a top-level
catch, it becomes a "hey, we need to clean up and notify" routine.
I suppose, technically speaking, you could consider a "safe" language is
one that provides 100% guarantee of the correctness of your source code.
It might not do what you want, but it'll do what the language says it will.
Indeed, when you look at it, one of the jobs of an OS like Linux is to
turn unsafe languages like C (where running off an array is undefined)
into a safe language (by defining it to dump core, say).
> If instead you meant some language that requires
redundant hardware, meticulously and constantly checks and corrects for
memory corruption, processor faults, hardware failures, etc. then I
guess you'd be right. I've yet to see such a language.
One must always keep in mind the separation of language from the
implementation thereof.
Sorry, I wasn't very clear with what I said. I meant more that it was
trickier to work around the problems. If you go in and actually correct
the implementation there really isn't necessarily any difference between
the two.
Oh. Hmm. I don't know that's quite right either. I don't think the
degree to which the behavior of a language is well-defined has much
affect on how easy it is to work around bugs in compilers or libraries.
Almost by definition.
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
