Re: OT: Language War (Re: "C" Manual)
Lo, on Thursday, January 3, Erik Steffl did write:
> what's the difference? the point is you can assign almost anything to
> anything, and yet there is no segfault - i.e. the strength of types has
> nothing (sort of) to do with segfaults... the resource allocation is
> crucial...
Type safety (plus dynamic allocation) implies advanced memory
management. The converse is not true: you can slap Boehm's conservative
GC onto a C++ program, but you can still get segmentation faults:
char str[] = { 'b', 'a', 'd', ' ', 's', 't', 'r', 'i', 'n', 'g' };
// note the lack of a terminating '\0'!
cout << str;
No allocation issues involved. As Ben Collins pointed out elsewhere in
this thread (bit of a tree-shaped thread, isn't it?), this won't
necessarily cause a segfault, but it can. It's also a violation of
type-safety: cout expects a null-terminated string, and as far as the
compiler is concerned, str fits this. However, there's no runtime check
in the output routine to verify that this is, in fact, the case. Ooops.
Therefore, I claim that type safety is a more fundamental concept than
resource mangement.
> that's all interesting, but the point was that the perl type system is
> as weak as I can imagine yet it doesn't lead to segfaults... it's the
> resource allocation!
Type safety != `strong' types. They're orthogonal. (Well, sort of. It
turns out that `strong types' isn't a very well-defined concept;
language researchers prefer to discuss compile-time type verification.
*That* definitely has nothing to do with type safety.)
> If you cannot make sure that MyUserType variable will only be assigned
> MyUserType values then you have (almost) NO type safety.
That's only meaningful if you can declare a variable to be MyUserType at
runtime. This does not apply to a whole variety of languages, many of
which are still type-safe.
(I think I'm just going to decide that Perl's type system is on crack.
But what do you expect when a linguist designs a programming language?)
> > In any case, memory allocation errors aren't the only cause of
> > segmentation faults---how about walking off the end of an array? Here,
> > I claim that Perl *does* maintain type-safety, although in a seriously
> > fscked-up way: it simply expands the array to make the reference valid.
>
> it's not the types! it doesn't care about types at all. it just makes
> sure you always have a place to store whatever you are about to store.
> what does that have with types? not much. it has to know what are you
> trying to store but it doesn't care at all what was there before, what's
> the type of variable where you are storing it. again, I find it pretty
> strange to call that kind of behaviour 'type safety'.
Yes, it *is* types. Remember the definition of type-safety:
If an expression E is determined at compile time to have type T,
then evaluating E will have one of two results:
1) The value of E is a valid object of type T and not just some
random collection of bits we're misinterpreting as a T.
2) a well-defined runtime error occurs (e.g., Java's
ArrayBoundsException).
There are no other possibilities.
In this particular case, Perl chooses to use the memory allocation
system to satisfy type safety (it creates a new T, initializes it, and
returns it). It's not the only possibility, though; Java would throw an
exception in this case. No allocation involved.
Richard
Reply to: