Re: OT: Language War (Re: "C" Manual)
Lo, on Wednesday, January 2, Erik Steffl did write:
> Richard Cobbe wrote:
> >
> > Lo, on Monday, December 31, Erik Steffl did write:
> >
> > Perl does have strong types, but they don't really correspond to the
> > types that most people are used to thinking of. Perl's types are
> >
> > * scalars (no real distinction between strings, numbers, and the
> > undefined value)
> > * lists
> > * hashes
> > * filehandles
> >
> > (I haven't really used Perl since Perl 4, so this list may not be
> > complete.)
>
> actually there is real distinction between string and number, it's
> just that it's internal only (perl stores numbers and strings
> differently, it also treats them differently).
Since Perl automatically converts between strings and numbers whenever
it feels like it, there's really no important distinction between the
two from the programmer's perspective. (In other words: since you can't
tell if a Perl scalar contains the number 33 or the string '33', there's
no practical difference between the types.) Implementation details are
really pretty irrelevant at the level at which I'm discussing the
language.
> the point was that it's not a strong type system - by which I mean
> that you can assign pretty much any value to any l-value, no questions
> asked. You don't get segfault but you still get non-working program
> (e.g. when you mistakenly assing array to scalar, you get size of array
> in scalar).
Oh, right. I'd forgotten about the whole scalar/array context thing.
(You can tell that I don't use Perl that often, yes?) Since, however,
the following two statements aren't inverses
$bar = @foo;
@foo = $bar;
(the latter sets @foo's length, does it not?) I'd be tempted to explain
the list-to-scalar conversion in terms of an implicit conversion, much
like those performed by C++ in the presence of, say, single-argument
constructors.
Even if that doesn't work, though, then you can take the LISP tactic,
and just consider everything to be the same (static) type:
ThePerlDataType. This type has several variants for scalars, lists,
references, and so forth.
> the reason you don't get segfaults is that perl takes care of memory
> allocation, e.g. if you try to assign something to the variable that's
> undefined (no storage place yet), it allocates appropriate amount of
> memory or if you try to read a value of variable that doesn't have value
> it says that undefined variable was used (doesn't give you random piece
> of memory like you can get in c).
>
> > > most of the segfaults are because of the resource allocation mistakes,
> > > not because of mistaken types... at last that's my impression.
> >
> > Resource allocation mistakes (at least, the kind that typically lead to
> > seg faults) *are* type errors, from a certain point of view.
>
> when you stretch it far enough.
It's not a stretch at all; it simply requires thinking about types in a
way not very common among C/C++/Java programmers.
> generally there are two distinct problems: [resource allocation
> errors and type errors]
I'll agree that the two are related; in fact, I'd go so far as to say
that if a language supports dynamic memory allocation and type-safety,
it *has* to have some sort of automatic storage management system.
Otherwise, you can delete objects too early and cause problems. My
original point, though, was that early deletions like this actually
short-circuit the type system, since they break the type-safety
invariant.
> IMO it's good to have clear distinction between resource allocation
> and type safety. example of perl - it doesn't have type safety, it lets
> you assing (almost) anything to anything but you still don't get
> problems as you describe above because it handles the memory allocation
> automatically.
Perl's a little weird, I'll grant you, but the fact that you can do this
sort of `free assignment' doesn't preclude typesafety. Ferinstance, in
Scheme, I can do this without any problems:
(define x 3) ;; variable definition & declaration
(set! x "three") ;; variable assignment
Works just fine. Of course, if I then try to add x to 4 after the set!,
I'll get a run-time error---thus type-safety.
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.
> > Performing run-time checks, as with array indexing, does not necessarily
> > imply the existence of an interpreter. If a compiler sees the
> > expression a[i], it can either assume that i's value is a valid index
> > for the array a (as C and C++ do), or it can insert the appropriate
> > checks directly into the executable code. I still claim this is part of
> > the language's run-time system, regardless of how it's interpreted.
~~~~~~~~~~~
Erm, that should have read `implemented' -- sorry.
> just because something does same thing it doesn't mean it's the same
> thing. there are two extremes - on one side is e.g. c program that
> doesn't use any libraries or standard start-up code. on the other side
> there's e.g. VB that requires interpreter to run.
>
> run time checks was just one example, the point is that HW is
> generally simpler and compiled languages tend to have less extra stuff,
> SW interpreters are generally more complex and cary extra baggage (not
> saying it's a bad thing).
Oh, I see. You're drawing a distinction between C and C++ (the
`compiled' languages) on one side, and Java/Scheme/VB/Perl (the
`interpreted' languages) on the other. This is a common conception, but
it's not actually the case. It's quite possible to compile Scheme
directly to object code; I've used systems that do this. Similarly,
there exists an interpreter for C programs.
> I think there's clear distinction between java VM and standard
> libraries, as far as their relationship to the actual program goes.
Yes. But you can't implement, e.g., C++ exceptions in the standard
library.
It looks to me as though we're using the phrase `runtime system' in
different senses. This is a disagreement, IMO, that's really not worth
getting too worked up over.
Richard
Reply to: