Re^9: use fields; # damnit

[stvn]

I think you'll probably confuse a fair number of people

You are right, my defintions are both ambigious and not quite right. That said, the definitions you provide are overly simplistic, and in places debatable. So lets get down to specifics.

I see a type-system as being composed of 2 parts. The first part is a set of rules for defining types within a language. The second part is how those types interact, which can be broken down into; type equivalence, type compatability (which includes rules for type conversion and casting) and type inference (rules for figuring out types).

When I said I did not think of ML as staticaly typed, I was mistakenly only including the first part. ML's types are optionally statically defined, however the end result of ML's compilation process is a static type determination. In the end, my defintion of ML as not being staticly typed is wrong. However, ML (and similar lanaguges like Haskell) is not that easily classified.

Your defintion of a strongly typed language is simplistic.

The language knows what type something is.

A strongly typed langauge is usually considered to be a language in which (through the langauge implementation) the rules of the type use can be enforced. Meaning that it can ensure that only those operations which are supported by a certain type can be applied to that type. It is not enough to just know it, you must be able to enforce it. By my defintion, perl is not really a strongly typed language. While it does know much about the types, it does not always enforce the rules of that type (sometimes only warning the programmer).

Your defintion of weakly typed langauges is also not quite clear.

You have to figure out what type something is (C, assembler, etc.)

The fact is that there are no types in assembly langauges at all (at least not any I am familiar with, which truthfully is not that many). C is on the other hand has the first part of a type system (means of defining a type) and most implementations will enforce the rules of the second part at compile time (one of the reasons C is so fast is that it has very little (if any) run-time checking in most implementations). C does have several loopholes in its type system though which allow the rules to be broken or bent (union types are one example). So while C's type system is not perfect and might be viewed by some as weakly implemented, I don't know if I would really call it weakly typed. I certainly would not group it with the type-less assembler.

I would be hesitant to define weakly typed lanagues, since most all languages have some notion of types, and do some checking to enforce their usage. I would think that it is best to just look at the degrees of strength of a type system, rather than just define it as weak, but I might be just splitting sematic hairs here.

Your defintion of static is also little unclear.

We know what type something is at compile time

A staticly typed langauge is usually thought of as a strongly typed language in which types can be checked at compile time. What your defintion above does not say is the strongly typed part. This is important because it is not enought to just know something if you don't have the means to do anything about it. Very few languages are purely staticly typed, even Ada will leave some things to be checked at run-time.

Your defintion of dynamic is also unclear and not complete.

We know what type something is at run time

Sometimes a dynamicly typed language will not know what type something is at all and assume the programmer is doing the right thing (this is true of some situations in some implementations of LISP and Scheme), and some lanaguges usually considered statically typed (like Ada and Pascal) will defer some checks till run-time. Dynamic binding is also usually associated with late-binding languages like Smalltalk in which a variable is essentially a pointer and its actual type association is put off till the last minute.

The problem I think in defining typing too much is that very few languages will ever fit easily into your defintions. Most langauges will blur the edges and cross a few lines.

[Aristotle]

By my defintion, perl is not really a strongly typed language. While it does know much about the types, it does not always enforce the rules of that type (sometimes only warning the programmer).

Try treating a hash like a scalar. Or a scalar ref like an array ref.

Perl is strongly typed.

You are confusing the type associated with the name of a variable with the type associated with its value. In C, you declare a type for the name of a variable, as in double i;, but the content of i can be anything. The language just won't let you assign from a variable with name declared to be of one type to a variable with a name declared to be of another. It doesn't actually know what the variables contain, however.

In Perl, that's different. The language always knows the type of the content of each variable.

[stvn]

Try treating a hash like a scalar. Or a scalar ref like an array ref.

You can however treat a number like a string and a string like a number in many cases. And while the "public" type system my just call all these scalars, the underlying implementation makes a distinction (i think it is IV and SV types, i don't recall exactly).

And then there is of perl's idea of contexts. I can use an array like a scalar and get back its length. I can assign an array to a hash without too much trouble if the array has an even number of elements. This adds a level of flexibility (and sometimes confusion on the part of the programmer) to perl's type system which keeps me from seeing it as a truely strongly typed language. Yes, it's closer than some, but IMO its not that close. However just as TIMTOWTDI, there is more than one way to look at it too.

As I said, it is very difficult to classify a language as having a specific type system, most all will blur the lines and defy strict classification. One of the great things about perl IMO is its inability to be classified.

[Aristotle]

When I say "treat a hash like a foo", I mean interpreting the bytes in memory that make up a hash (or more generally, the internal representation of any hash) in a different way. That isn't possible in Perl.

There are defined and specified mechanisms for type conversions, and you can indeed convert any type to any other in some fashion, but you're always converting the values, never casting them.

In that sense, Perl is indeed strongly typed, whereas C is truly a glorified assembler.