Re: OT: Language War (Re: "C" Manual)
Richard Cobbe wrote:
>
> 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
???
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...
> 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.
well, mostly...
> > 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.
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!
> > 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.
that's true, to certain extend.
> > 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 this case yes, in other cases, no. I can't speak of lisp but in
perl it's definitely not what I would call type safety. it makes sure
that proper amount of memory is allocated but it doesn't care about
types much. if you cannot make sure that MyUserType variable will only
be assigned MyUserType values then you have (almost) NO 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.
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'.
> > > 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.
it actually makes almost the same sense both ways...
> > 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.
that's what I wrote before! (about c interpreter and java compilers)
the point is that SW runtime is generally more flexible, is able to hold
more status information about program and therefore make the crash a
little bit like soft landing. what you call runtime error in programs
with SW runtime is the equivalent of segfault or bus error in programs
with HW runtime.
in C interpreter you'd have no segfaults, you'd have runtime errors!
and you could fairly easily implement checking of the array indexes
etc... in C programs that run in HW it's not done because C is meant to
be that way (no extra stuff, you implement everything (=as much as
possible) yourself (=in libraries)).
> > 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.
not sure what you're getting at. you can't implement certain features
in libraries, generally the program control is part of the language and
therefore not part of libraries. exceptions are on the same level as for
loops, function calls, goto statements etc, none of those are
implemented in libraries, that's what the language structures are
compiled into.
> 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.
well, it's good to exaplin both...
but the main point was the type safety and resource allocation, the
runtime was just a side show...
erik
Reply to: