strong/weak typing and pointers

[Mike Meyer]

Gabriel Zachmann writes:
In summary, there are basically three interpretations of "weak-typing" discussed
in this thread:

(1) A language is "weakly-typed" if it allows code to take a block of memory
that was originally defined as one type and reinterpret the bits of this block
as another type.

(2) A language is "weakly-typed" if it has a large number of implicit coercions.

(3) A language is "weakly-typed" if it often treats objects of one type as other
types.

Definition 1 is the definition most commonly used in Programming Languages
literature, and allows a language to be called "weakly-typed" based only on the
language definition. However, for all intents and purposes, it is only
applicable to statically typed languages; no one on the list could come up with
a dyamically typed language that allowed bit-reinterpretation.

Definition 1 is a black/white proposition instead of being a
continuum. Once you allow the simple case needed for real-world work
of allowing an object to be treated as whatever it is or a sequence of
bytes, you can treat any type as any other type.

Definition 2 seemed to be the definition most commonly used on the list, most
likely because it is actually applicable to a dynamically typed language like
Python. It has the problem that in a language that supports operator
overloading (like Python), programmers can make their language more
"weakly-typed" by simply providing additional coercions, thus whether or not a
language is called "weakly-typed" depends both on the language definition and
any code written in the language.

This problem can largely be made to go away by limiting it to builtin
types. Likewise for definition 3.

I'd call Ruby's allowing builtin types to be changed a
misfeature. Builtin types should be subclassed.

<mike

 

[Michael Hobbs]

The reason for this is that at any given time in OCaml, the sequence of bits is
only interpretable as *one* of the two types, never both. If you have a good
example of using a union (in C probably, since OCaml wouldn't let you do this I
don't think) where you want to treat a given sequence of bytes as both types *at
once*, that would be great!

I've come up with the perfect example for you. However, it is from
the days when memory was scarce and programmers were allowed to use
any programming language they wanted, so long as it was assembly.

To conserve as much memory as possible, some programmers would use
machine code that was loaded into memory as their integer constants.
Here is an excerpt from The Story of Mel:
(http://www.catb.org/~esr/jargon/html/story-of-mel.html)

Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.

 

[Alex Martelli]

Apple did this in early versions of the Memory Manager
of classic MacOS, using the upper 8 bits of a Handle
for various flags. You weren't supposed to make any
assumptions about what the upper byte contained, but
of course some people did... and their applications
broke when 32-bit addressing came in...

I believe many implementations of high-level languages on machines where
addresses had to be aligned used LOW bits similarly. Say addresses of
integers need to be even or else a bus error will occur. Then, a word
that is used to hold an integer address has its low bit 'available' as a
flag -- it needs to be cleared before it's dereferenced, anyway.

This seems reasonably sound because, even if a later model of the CPU
should be extended to allow misaligned addresses, the OS need not
support that. Misaligned addresses can pay substantial performance
prices for little gain -- not sure about the state of play these days,
but just a few years ago you could boost the performance of some C codes
on intel CPUs (which always allowed address misalignment) quite a bit by
recompiling with flags telling the compiler to ensure addess alignment.

So, the low bit, when set, could indicate we're pointing to a Bignum
(like a Python long), when clear, that we're pointing to an ordinary
small integer, for example -- or other such dychotomous distinctions.

Of course, such an address-plus-flag must be handled as a bitmask (to
examine and clear the flag) or a pointer, interchangeably.


Alex

 

[Carl Banks]

Here's a first stab at one:

In summary, there are basically three interpretations of "weak-typing" discussed
in this thread:

[snip]


It seems to me that "weak/strong" description of typing is too
overloaded to be very specific. Everyone seems to mean something
different by "weak" typing. Some mean the ability to reinterpret
bits. Some mean ability to do a lot of implicit conversions. Some
(not anyone here, of course) mean dynamic typing. And I'm sure some
mean something else.

I recommend we stop using "weak/strong typing" as a technical term,
and leave it to be a meaningless buzzword for the ignorant peasantry.

Instead, we should define several other scales, with very specific
names. I'll make some suggestions. One thing to keep in mind is that
these are, in fact, spectra; many languages will not be one extreme or
the other.

Static/dynamic typing we already know about.

About the ability to reintepret bits: it seems that the essence of
this is that bits can be reinterpreted under different
_circumstances_. So a good, specific name for this distinction might
be "manifest/circumstantial typing". The words are a bit long, yes,
but off-hand I can't think of any shorter words that are specific
enough. Words like "loose", "flexible", etc. could mean a lot of
things, just as "weak" does. "Circumstantial" is somewhat more
specific, but still could mean a few different things. Maybe it
should just be "bit-reinterpretable"? "Manifest" might not be a good
word, either, since it's kind of discrete in meaning. Can something
be "less manifest"? Suggestions welcome, of course.

About the cramming of many different representations into a single
type, abused to the extreme by Perl: we might call this "overloaded
typing". Two things I don't like about it: first, it has a slightly
negative connotation (I'd prefer that terminology be neutral, which is
another reason I didn't like "strong/weak"), and second, it's not
clear what the opposite aspect should be called. Perhaps we could
coin some terms such as "polybasic/oligobasic/monobasic". (I would
have suggested "polymorphic" but it was taken .

About the implicit type conversions: this I find the hardest to name.
The best I can come up with is "coercive/restrictive". I think we
need a better suggestion. I really think this label only make sense
for predefined operations, and maybe some functions. If I write a
function "def a(b): b=int(b); ...", is that coercive in the same
spirit as "a" + 1 in Java? I would say not. In fact, I would say
this isn't even a property of the typing. We should probably say that
a language is a "type-coercive language" rather than that it has
"coercive typing". Actually, we should say it's something else, cause
I just don't like the term coercive. Maybe "type-general" vs
"type-specific"? Seems to vague. "Type-tolerant" vs "type-picky"? I
don't know. Suggestions?

So, to summarize, I recommend we do away with "strong/weak." We
replace it with four spectra, with some suggested names:

static/dynamic
manifest/circumstantial
monobasic/polybasic
coercive/restrictive*

 

[Gabriel Zachmann]

I had already compiled a little file of clips plus the two definitions I
had seen so far.

But your summary is better, so it goes into my summary file, too. ;-)


Cheers,
gabriel.

--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| (e-mail address removed)-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

 

[Dave Benjamin]

One word: union

Interestingly, unions can be well-defined even in a strongly-typed
language, e.g. OCaml:

# type int_or_list = Int of int | List of int list;;
type int_or_list = Int of int | List of int list
# Int 1;;
- : int_or_list = Int 1
# List [1; 2];;
- : int_or_list = List [1; 2]

Unions in functional languages are also known as direct sums of types (as
opposed to products, which form tuples). And trying to access a union that
holds an int as list will yield an error - runtime, most probably. So there
is no way of reinterpreting an int as list, which still satisfies the
paragdigms of a strong typed language.

Just FYI:

In OCaml, the error will be at compile time, and the compiler will warn you
if you do not deal with all possible cases for a given union type.

 

[Stefan Axelsson]

It seems to me that "weak/strong" description of typing is too
overloaded to be very specific. Everyone seems to mean something
different by "weak" typing. [...]
I recommend we stop using "weak/strong typing" as a technical term,
and leave it to be a meaningless buzzword for the ignorant peasantry.

You're not alone. Wikipedia lists 8 (!) different meanings for the term
"Strong typing" (http://en.wikipedia.org/wiki/Strong_typing):

I quote:
-----------------------------------------------------------------------
Note that some of these definitions are contradictory, while others are
merely orthogonal.

Because there is no generally-agreed meaning for the phrase
"strongly-typed language", it is possible to find authoritative
statements that many languages both are and are not strongly-typed. For
example, under definitions 1, 2, 3, and 8, the C language is strongly
typed; under 4, 5, and 6 it is weakly typed. Accordingly, it is easy to
find people who will claim that C is a "strongly-typed language" and
others who will claim that it is a "weakly-typed language".

Programming language expert Benjamin C. Pierce has said:

I spent a few weeks . . . trying to sort out the terminology of
"strongly typed," "statically typed," "safe," etc., and found it
amazingly difficult. . . . The usage of these terms is so various as to
render them almost useless.

 

[Greg Ewing]

I recommend we stop using "weak/strong typing" as a technical term,
and leave it to be a meaningless buzzword for the ignorant peasantry.

How about:

solid typing -- sharp boundaries between types, few
automatic coercions

fluid typing -- lots of automatic coercions

(Don't ask me what "gaseous typing" might mean...)

 

[Gabriel Zachmann]

I have tried to summarize this thread and created a new article on the
Python Wiki at

http://www.python.org/moin/StrongVsWeakTyping

HTH,
Gabriel.

--
/-------------------------------------------------------------------------\
| There are works which wait, |
| and which one does not understand for a long time; [...] |
| for the question often arrives a terribly long time after the answer. |
| (Oscar Wilde) |
+-------------------------------------------------------------------------+
| (e-mail address removed)-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

 

[Carl Banks]

How about:

solid typing -- sharp boundaries between types, few
automatic coercions

fluid typing -- lots of automatic coercions

Very nice. I bow to your metaphorical creativity.

(Don't ask me what "gaseous typing" might mean...)

Compiler builds a directed graphs of type conversions and always
chooses the shortest path.


actually-gases-are-fluids-too-ly yr's,

 

[Martin Maney]

solid typing -- sharp boundaries between types, few
automatic coercions

fluid typing -- lots of automatic coercions

(Don't ask me what "gaseous typing" might mean...)

Surely that would be typing by context, no?

 

[JCM]

How about:

solid typing -- sharp boundaries between types, few
automatic coercions

fluid typing -- lots of automatic coercions

(Don't ask me what "gaseous typing" might mean...)

I think both liquids and gases are considered fluids. Liquid Typing
and Gaseous Typing would be sub-categories.

 

[Greg Ewing]

I think both liquids and gases are considered fluids. Liquid Typing
and Gaseous Typing would be sub-categories.

Hmmm. So maybe with liquid typing, your data sloshes
around in the bottom of your address space, whereas
with gaseous typing, it expands to fill all available
memory...

 

[Tim Hoffman]

Hmmm. So maybe with liquid typing, your data sloshes
around in the bottom of your address space, whereas
with gaseous typing, it expands to fill all available
memory...

Continuing in this theme, does this mean that phase transition (between
solids and fluids ) typing, is typing of an indeterminate nature ;-)

Oops now that we are on the slippery slope of metaphors ;-) do we class
super cooled liquid types as ones that can be co-oerced but just take a
very long time ;-)

Tim

 

[Michael Hobbs]

I think both liquids and gases are considered fluids. Liquid Typing
and Gaseous Typing would be sub-categories.

I was thinking that "rigid" would be the antonym of "fluid".

I'm not sure which would be the most accurate juxtaposition:
solid vs. liquid
or
rigid vs. fluid
or
gaseous vs. plasmatic
or
sticky vs. solvent
I could go on...

- Mike

 

[Andrew Dalke]

Oops now that we are on the slippery slope of metaphors ;-) do we class
super cooled liquid types as ones that can be co-oerced but just take a
very long time ;-)

Or perhaps since supercooled fluids have all particles in the
lowest quantum state, the metaphor is that everything gets treated
as the root Object type?

Andrew
(e-mail address removed)

 

[Carl Banks]

I was thinking that "rigid" would be the antonym of "fluid".

You are correct, of course. However, I don't like "rigid" as a term
to describe typing, for a simple reason: it's not specific enough.

Unlike solid, rigid can easily refer not only to substances, but also
to stances, or laws, or hierarchies, or guidelines, etc. Rigid is
sometimes used as a synonym for strong (hopefully not by engineers).
Because it has a very general meaning, "rigid typing" could be
construed as meaning a lot of different things.

OTOH, solid tends to refer specifically to substances. It is the
metaphor to substances which, IMO, makes solid a good term for this
aspect of typing. Solid substances don't deform under pressure;
likewise, solid typing systems to convert the types under pressure.

If someone hears the term "rigid typing", they could conceivably take
it to mean "static typing" or (my definition) "manifest typing". But
if they hear "solid typing", then it's a stretch to take it to mean
"manifest typing" and a bigger stretch to take it to mean "static
typing".

On the opposite end, I think I actually would prefer "liquid" to
"fluid". Fluid would be ok; unlike with rigid, there are no fluid
stances or fluid laws, although there are fluid guidelines. Fluid
isn't as general in meaning as rigid is. However, the word liquid
definitely stresses the metaphor with substances a lot better then the
word fluid does.

 

[Jeff Shannon]

I was thinking that "rigid" would be the antonym of "fluid".

You are correct, of course. However, I don't like "rigid" as a term
to describe typing, for a simple reason: it's not specific enough.

Unlike solid, rigid can easily refer not only to substances, but also
to stances, or laws, or hierarchies, or guidelines, etc. [...]

On the opposite end, I think I actually would prefer "liquid" to
"fluid". Fluid would be ok; unlike with rigid, there are no fluid
stances or fluid laws, although there are fluid guidelines. Fluid
isn't as general in meaning as rigid is. However, the word liquid
definitely stresses the metaphor with substances a lot better then the
word fluid does.

On the other hand, I personally think that "rigid/fluid" make a better
metaphor specifically *because* they are not tied so much to physical
properties -- they are terms that have already been generalized as
metaphor in the much same way as is intended here. The parallel with
rigid stances, rigid hierarchies, etc, is an appropriate one -- in all
such cases, we're talking about something that resists attempts to
change its nature and/or form. Similarly, "fluid" connotes "easily
conforming to its environment", an apt description of the behavior of
objects in a language full of automatic conversions/coercions. At least
to me, the most obvious interpretation of both terms is the situation
we're discussing here

Jeff Shannon
Technician/Programmer
Credit International

 

[Carl Banks]

I was thinking that "rigid" would be the antonym of "fluid".

You are correct, of course. However, I don't like "rigid" as a term
to describe typing, for a simple reason: it's not specific enough.

Unlike solid, rigid can easily refer not only to substances, but also
to stances, or laws, or hierarchies, or guidelines, etc. [...]

On the opposite end, I think I actually would prefer "liquid" to
"fluid". Fluid would be ok; unlike with rigid, there are no fluid
stances or fluid laws, although there are fluid guidelines. Fluid
isn't as general in meaning as rigid is. However, the word liquid
definitely stresses the metaphor with substances a lot better then the
word fluid does.

On the other hand, I personally think that "rigid/fluid" make a better
metaphor specifically *because* they are not tied so much to physical
properties

Just to nitpick: something with a vague meaning really isn't a
metaphor so much as a literal description in a different sense of the
word.

If you don't like how the word solid is tied to material properties,
then it seems to me that your real problem with it is that you just
don't like metaphors. Personally, to me, it doesn't matter too much.
I am equally comfortable with either metaphorical or literal
descriptions.

My criteria is not whether the meaning is literal or figurative, but
whether it's specific. Solid is; rigid isn't.

-- they are terms that have already been generalized as
metaphor in the much same way as is intended here. The parallel with
rigid stances, rigid hierarchies, etc, is an appropriate one -- in all
such cases, we're talking about something that resists attempts to
change its nature and/or form. Similarly, "fluid" connotes "easily
conforming to its environment", an apt description of the behavior of
objects in a language full of automatic conversions/coercions. At least
to me, the most obvious interpretation of both terms is the situation
we're discussing here.

Let me try to explain why I disagree with this. If you paid attention
in your study of grammar, you might be aware that there are two use
cases for adjectives: descriptive and restrictive. A descriptive
adjective (word, phrase, or clause) gives information about the noun,
whereas the restrictive adjective tries to distinguish it.

I don't have any problem using rigid in a descriptive sense. It is a
wholly accurate description.

In a restrictive sense, it simply doesn't do the job: it's too
applicable to other dimensions of typing. Rigid could easily be taken
to mean inability to reinterpret bits, and it's not a stretch at all
for it to be taken to refer to static typing. It's certainly _most_
appicable to the implicit casting scale, but not _only_ applicable.
The drop-off in applicabilty to other dimensions is simply not enough.
It's too vague to be a name.

OTOH, solid has a specific (literal) meaning that is very analogous to
its proposed use (hence its suitability as a metaphor). Thus it
qualifies as a name much better than rigid does.

That's it really. It has nothing to do with how well it describes the
typing; just how well it identifies it. We've seen names like strong
and weak utterly fail to identify what they mean, because they're
vague. It would be the same with rigid.

 

[Jeff Shannon]

Just to nitpick: something with a vague meaning really isn't a
metaphor so much as a literal description in a different sense of the
word.

From www.m-w.com, "metaphor" is:

*1* *:* a figure of speech in which a word or phrase literally denoting
one kind of object or idea is used in place of another to suggest a
likeness or analogy between them (as in /drowning in money/); /broadly/
*:* figurative language -- compare SIMILE
<http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=simile>


Please note that the use of the phrase "rigid guidelines" is indeed
figurative language. One is figuratively likening the strict adherence
to a set of rules to the physical property of inflexibility.

I also disagree with your assertion that rigid has a vague meaning. It
has a *very* specific meaning, and that meaning is "lacking flexibility"
(again from www.m-w.com -- "*1 a* *:* deficient in or devoid of
flexibility"). And for the record, "solid" has more alternative
definitions in said dictionary than "rigid" does.

If you don't like how the word solid is tied to material properties,
then it seems to me that your real problem with it is that you just
don't like metaphors. Personally, to me, it doesn't matter too much.
I am equally comfortable with either metaphorical or literal
descriptions.

On the contrary, I'm quite comfortable with metaphor. However, I
completely disagree with your assertion that "rigid rules" is not a
metaphorical usage of the word "rigid". It is an entirely standard and
commonplace usage, yes, but that does not make it non-metaphorical.
Everyday language can be (and often is) figurative, too.

If you paid attention
in your study of grammar, [...]

Please don't assume that someone who disagrees with you is either
uneducated or stupid. It's rather insulting and wholly inappropriate.

OTOH, solid has a specific (literal) meaning that is very analogous to
its proposed use (hence its suitability as a metaphor). Thus it
qualifies as a name much better than rigid does.

On the other hand, I could posit that "solid typing" could be seen as
implying that objects are opaque black boxes, and thus that it's related
more to data-hiding than to lack of type coercions.

I'm not convinced that the physical property of solidity is a more
compelling metaphor, and is less prone to alternative interpretations,
than the physical property of rigidity. Indeed, after looking at the
dictionary definitions of both words, I find the case for "solid" to be
even *more* vague. The first given definition of "rigid" as "lacking
flexibility" leads one immediately to the idea that is being discussed
here. "Solid", on the other hand, has a first definition of "being
without an internal cavity" -- how does *that* relate to types? And
your attempts to simply repeat your assertions while insulting me don't
make your argument any more convincing.

Jeff Shannon
Technician/Programmer
Credit International