strong/weak typing and pointers

[Christophe Cavalaria]

Steven Bethard wrote:

> Christophe Cavalaria <chris.cavalaria <at> free.fr> writes:
>> 
>> One could say that the common definition of weakly typed languages
>> cannont apply for a dynamicaly type language. Let's face it, once you've
>> implemented a dynamicaly typed language, it seems very hard to use one
>> piece of data as the wrong type.
> 
> While I agree that it would be kind of foolish to implement a dynamically
> typed language that wasn't strongly-typed (PL theory definition), there's
> no reason you *couldn't* -- your language would just need to provide some
> sort of 'cast' function that did the conversion at runtime.
> 
> For example, say the memory block for an object instance was allocated
> like:
> 
> [0] pointer to class object
> [1] pointer to dictionary object (holding variables)
> 
> Then maybe you could do something like:
>   int1, int2 = cast(object(), list(int))
> Given, I can't see any use for such behavior, but you *could* do it if you
> had a
> weakly-typed dynamic language and you knew how it allocated objects.  At
> some level, you always have bits -- whether it makes any sense to
> reinterpret them depends on exactly what the bits originally meant.

In any good dynamicaly typed language, the object must know what it is thus
there is no way to do a reinterpret_cast like in C or C++. It is
meaningless. Doing it anyway is insane as you have pointed. It's only goal
beeing to add in the flaws of the weakly static typed languages to a
contrived example.

>> What we can do is extend the definition of weakly typed language to
>> something like : "A weakly typed language is a language that often uses
>> incorectly some piece of data by applying to it the wrong type" Such
>> definition would include any language that is too liberal with the type
>> coertion like php.
> 
> Don't get me wrong -- I do understand your point.  In every case I can
> think of, there is no reason to want weak-typing (PL theory definition) in
> a
> dynamically-typed language.  On the other hand, I haven't really seen any
> good cases for wanting weak-typing in a statically-typed language either.
> 
> Note that PHP doesn't fit your definition above anyway.  When PHP allows:
> 
> "a" + 10 == 10
> 
> it's not incorrectly using "some piece of data by applying to it the wrong
> type".  It's doing exactly what it tells you it'll do.  This is *correct*
> response given the PHP language definition.

Incorrectly is a view of the mind in that case. From my point of view it is
incorrect. And you could argue that taking a float * and casting it into a
int * gives us a predictable behaviour. It'll still be wrong to do it
unless it was exactly what you wanted to do. And in that case you can
create explicit language constructs to do the trick.

> In addition, you *can* create a statically-typed language that is strongly
> typed
> (PL theory definition) but also very liberal with type coercion.  What
> would you
> call such a language?  Since being liberal with type coercion and allowing
> bit reinterpretation are orthogonal, why not keep the two separate terms?
> 
> My issue here is that I don't think we should confuse an already easily
> confused
> term by giving it a second meaning.

I see your point but I must add that I wasn't giving that term a second
meaning. Just like in mathematics when you take a theory and you create a
new theory that encompases the old one, I was giving a new definition for
the term.

> If there aren't any dynamically typed 
> languages that are also weakly-typed, that's ok -- it doesn't mean we
> should change the meaning of "weakly-typed" for these languages.
> 
> Steve