strong/weak typing and pointers

Alex Martelli <aleaxit <at> yahoo.com> writes:

Suppose for example that you would like your OS to be able to load
executable code from disk into memory and execute it. Suppose you would
like it to be able to read some configuration parameters from disk and
set its own internal data structures accordingly. At one level, as it
goes to disk or comes back from there, you have arrays of bytes. But in
memory, you want functions that can be called appropriately (a device
driver residing in a module) or data structures which, differently from
an array of byte, DO have structure -- for example, a partition table
for a disk, with information to specific filesystem drivers as to what
partition is to be treated in what way.

I'm sorry, I guess I still don't understand this example. It sounds like you're
just going between untyped (array of bytes) and typed (functions, data
structures, etc.) I'm not seeing how you're, for example, casting a function to
a data structure, or a data structure of one type to a data structure of another
type.

Anything can (and sometimes should) be treated just as an array of bytes, in an
analogous method to how in an OO language with a base class Object, sometimes
it's appropriate to treat a given instance of a class as an Object, rather than
it's particular subclass of Object. I wouldn't consider treating function, data
structures, etc. as arrays of bytes (or vice versa) as something that takes
advantage of "weak-typing", but rather something that takes advantage of the
ability to treat data as untyped.

Hopefully this clarified my confusion and when you get a chance, you can try to
explain it to me again? Thanks,

Steve

Jul 18 '05 #52

Diez B. Roggisch <deetsNOSPAM <at> web.de> writes:

I'd second that - writing apus in php can lead to great surprises of what
actually happens - take this for example:

$foo = "abc";
$foo[0] = 65;

The result is

"6bc"
If I learned nothing else from this thread, I learned that I *never* want to
screw around with PHP. ;)
And don't forget: If you don't like the way someone overloaded some
operator, you can alter that behaviour according to your own design
philosophies.

Python has the nice property that you're not allowed to modify builtins, so no
one can ever make your Python code do anything other than:

foo = 'abc'
foo[0] = 65

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: object does not support item assignment

I wonder what people think about Ruby, which, I understand, does allow you to
modify builtins. Can anyone tell me if you could make Ruby strings do the
horrible coercion that PHP strings do?

Steve

Jul 18 '05 #53

> I'm sorry, I guess I still don't understand this example. It sounds like

you're just going between untyped (array of bytes) and typed (functions,
data
structures, etc.) I'm not seeing how you're, for example, casting a
function to a data structure, or a data structure of one type to a data
structure of another type.

Anything can (and sometimes should) be treated just as an array of bytes,
in an analogous method to how in an OO language with a base class Object,
sometimes it's appropriate to treat a given instance of a class as an
Object, rather than
it's particular subclass of Object. I wouldn't consider treating
function, data structures, etc. as arrays of bytes (or vice versa) as
something that takes advantage of "weak-typing", but rather something that
takes advantage of the ability to treat data as untyped.

Hopefully this clarified my confusion and when you get a chance, you can
try to
explain it to me again? Thanks,

I think what Alex means is that if you allow for re-interpreting data as
simply byte arrays and the other way round, you end up with exactly the
weak typing you defined before: The arbitrary reinterpretation of memory
portions.

Consider this simple example:

int main() {
float f = 13345.0;
void *mem = (void*)&f;
int *i = ((int*)mem);
printf("%f, %i, %d\n", f, mem, *i);
}

For read-only-cases (read-only with respect to the RAM) one might be able to
allow access to the memory without opening the weak-typing loophole. But if
you want read bytes into memory, you'll end up with an array of bytes
firsthand, and whatever interpretation you impose on it by casting, there
is no way of forbidding a wrong casting.
--
Regards,

Diez B. Roggisch

Jul 18 '05 #54

> I wonder what people think about Ruby, which, I understand, does allow you

to
modify builtins. Can anyone tell me if you could make Ruby strings do the
horrible coercion that PHP strings do?

I've no idea of how well ruby developers deal with the possibility to
redefine their builtins - but it sure scares the hell out of _me_, so I'm
glad the BDFL chose not to allow us to shoot large holes into various
bodyparts by making them unmodifiable...

--
Regards,

Diez B. Roggisch

Jul 18 '05 #55

Diez B. Roggisch <deetsNOSPAM <at> web.de> writes:

I think what Alex means is that if you allow for re-interpreting data as
simply byte arrays and the other way round, you end up with exactly the
weak typing you defined before: The arbitrary reinterpretation of memory
portions.

Consider this simple example:

int main() {
float f = 13345.0;
void *mem = (void*)&f;
int *i = ((int*)mem);
printf("%f, %i, %d\n", f, mem, *i);
}

Ahh, ok, I understand where he was going now, thanks.

However, this doesn't really address my concern. Clearly, allowing you to treat
things as untyped *allows* you to cast one type of structure to another, but it
definitely doesn't *require* you to do so. In your example, yes, casting to
(void*) lets you cast a piece of memory back and forth between float and int,
but I still don't know when I would actually want to do that...

Does this make my concern any clearer? What I'm asking for is an example like
yours above that not only shows that you can treat, say, the bits of a float as
an integer, but also shows why this would be useful.

Thanks again,

Steve

Jul 18 '05 #56

> Does this make my concern any clearer? What I'm asking for is an example

like yours above that not only shows that you can treat, say, the bits of
a float as an integer, but also shows why this would be useful.

The question is not so much if there is an actual usecase, but more that if
things _can_ be done, they inevitably _will_ be done. People have done so
all the time. I can remeber abusing 32bit pointers in 68k processors by
altering the most-significant byte. It took advantage of the fact that the
old 68k had only 24 address registers, thus ignoring the msbyte. That
allowed to pass 2 parameters in one pointer. And was for a short period of
time considered a clever trick....

Today, with lots of memory and faster processers, certain optimization
techniques that required creative reinterpretaiton of bits might have come
somewhat out of fashion - but the more low-level you get (e.g. drivers or
embedded devices) the more appaling they might look.

--
Regards,

Diez B. Roggisch

Jul 18 '05 #57

Diez B. Roggisch <deetsNOSPAM <at> web.de> writes:

Does this make my concern any clearer? What I'm asking for is an example
like yours above that not only shows that you can treat, say, the bits of
a float as an integer, but also shows why this would be useful.
The question is not so much if there is an actual usecase, but more that if
things _can_ be done, they inevitably _will_ be done.

No, the (my) question really was for an actual usecase. ;) People do a lot of
things in programming languages, not all of them particularly good or
appropriate. The recent example of intrinsics.replace to change the behavior of
Python's str class strikes me as one such example. =) I would be much more
convinced that weak-typing is useful if someone could actually use it for me. ;)
I can remeber abusing 32bit pointers in 68k processors by
altering the most-significant byte. It took advantage of the fact that the
old 68k had only 24 address registers, thus ignoring the msbyte. That
allowed to pass 2 parameters in one pointer. And was for a short period of
time considered a clever trick....

I'm not sure I see how this is taking advantage of weak-typing, unless I
misunderstand what you were doing here. Did you ever interpret your
two-parameter structure as anything other than either a set of bits or the two
parameters? You didn't ever treat the set of bits as a float, for example,
right? You *could* have, of course, but I'm guessing your interpretation of the
bits was consistent...

My point here is that I think in most code, even when people do a bunch of
bit-twiddling, they have a single underlying structure in mind, and therefore
you see them treat the bits as one of two things: (1) The sequence of bits, i.e.
the untyped memory block, or (2) the intended structure. IMHO, an example of
taking advantage of weak-typing would be a case where you treat the bits as
three different things: the sequence of bits, and two (mutually exclusive)
intended structures.

I guess I'm drawing a thin line here, but I see a difference between using the
untyped (bit-based) representation of a structure and actually converting a
structure between two different types.

Steve

Jul 18 '05 #58

Steven Bethard <st************@gmail.com> wrote:

Does this make my concern any clearer? What I'm asking for is an example
like yours above that not only shows that you can treat, say, the bits of
a float as an integer, but also shows why this would be useful.

Given a float, extract the (so-called) "mantissa" (what a misnomer!) and
exponent. Can you see the usefulness of _that_? Can you see that
treating the bits that compose the float as an int and using masking and
shifting is the obvious way to perform this task?

Say I need to compute some unary float function, such as 'sin', with
high speed and precision. One reasonable approach: normalize the float
input to a standard range (say 0 to pi/4, remembering what kind of sign
inversions &c you need to perform at result time); get "mantissa" (pah!)
and exponent and use the latter, partly to select the right lookup table
and partly to shift the mantissa appropriately to make it an index into
said result table, while keeping track of the bits that shifted out;
read out the result base and the multiplier for interpolation, multiply
the latter by the bits that shifted out and add the result to the result
base; perform sign or other symmetry inversions as previously recorded.

There -- you have the function computer to whatever precision is
requested, typically an ULP. Depending on your CPU, you may have HW
that obviates the need for some or all of these manipulations - but you
won't have it for all transcendentals, and what you don't have in HW
you'll need to do in SW -- and being able to get at the bits of the
floating point representation is often the best approach for that task.

Although the details were more antiquated, that was elementary stuff
taught in electronic engineers' first-year computing courses back in the
'70s, just in case we ever needed to code our own transcendentals (in
Fortran, of course -- you weren't expected to master machine code unless
you took computing electives in 3rd and later years, much less exoterica
such as Pascal, Lisp or APL). Is it considered advanced or specialized
these days?!
Alex

Jul 18 '05 #59

Alex Martelli <aleaxit <at> yahoo.com> writes:

[snip description of using integer parts of float representation]
Although the details were more antiquated, that was elementary stuff
taught in electronic engineers' first-year computing courses back in the
'70s, just in case we ever needed to code our own transcendentals (in
Fortran, of course -- you weren't expected to master machine code unless
you took computing electives in 3rd and later years, much less exoterica
such as Pascal, Lisp or APL). Is it considered advanced or specialized
these days?!

I'm obviously upsetting you, and I can see that we're still not quite
understanding each other. I have to assume that you're not the only one I'm
upsetting through these misunderstandings, so for the sake of the list, I'll
stop responding to this thread. Thanks everyone for a good discussion!

Steve

P.S. If anyone would like to know my response to the float representation
example, please contact me directly instead.

Jul 18 '05 #60

Steven Bethard <st************@gmail.com> wrote:
...

I'm obviously upsetting you, and I can see that we're still not quite
understanding each other. I have to assume that you're not the only one I'm
upsetting through these misunderstandings, so for the sake of the list, I'll
stop responding to this thread. Thanks everyone for a good discussion!
I apologize if I have given the impression of being upset. I am, in a
way, I guess -- astonished and nonplusses, as if somebody asked me to
justify the existence of bread -- not of some exotic food, mind you, but
of the most obvious, elementary, fundamental substance of earthly
sustenance (in my culture, and many others around it).
P.S. If anyone would like to know my response to the float representation
example, please contact me directly instead.

I promise not to ACT upset if you explain it here. So, we have an area
of 8 bytes in memory which we need to be able to treat as:
8 bytes, for I/O purposes, say;
a float, to feed it to some specialized register, say;
a bit indicating sign plus 15 for mantissa plus 48 for significand,
or the like, to perform masking and shifting thereof in SW -- a
structure of three odd-bit-sized integers juxtaposed;
and this is ONE example -- the specific one you had asked for.

Another example: we're going to send a controlblock of 64 bytes to some
HW peripheral, and get it back perhaps with some mods -- a typical
control/status arrangement. Depending on the top 2 (or in some case 4)
bytes' value, the structure may need to be interpreted in several
possible ways, in terms of juxtaposition of characters, halfwords and
longwords. Again, the driver responsible for talking with this
peripheral needs to be able to superimpose on the 64 bytes any of
several possible C-level struct's -- the cleanest way to do this would
appear to be pointer-casting, though unions would (as usual, of course)
be essentially equivalent. In Python, or another language that lets me
pack and unpack a struct to/from bytes in a controlled way (in Python's
case via the struct module) I can do that through a _copy_ -- I need to
go through a 'raw bytes' stage, cannot do the overlay directly; but
that's little more than a figleaf arrangement -- spending real CPU and
RAM operations because I can't be lowlevel/weakly-typed enough.
Alex

Jul 18 '05 #61

Steven Bethard <st************@gmail.com> wrote:
...

I wonder what people think about Ruby, which, I understand, does allow you to
modify builtins. Can anyone tell me if you could make Ruby strings do the
horrible coercion that PHP strings do?

Yes, you could. Reliable Ruby friends tell me that's not DONE in the
real world of Ruby, any more than pythonistas call their methods' first
argument 'foo' rather than 'self' or pepper their code with 'exec'
statements or code 200-chars nested-lambda oneliners. But though
culturally frowned on, it _is_ technically possible.

The one real example I saw, which was enough to turn me off my quest to
explore Ruby for production purposes, was making (builtin) string
comparisons case-insensitive -- apparently that _IS_ the kind of thing
_SOME_ perhaps-inexperienced Rubystas _DO_ perpetrate (breaking library
modules left, right, and center, of course). Maybe it's similar to
rather inexperienced Pythonistas dead keen on "exec myname+'='+value"; I
_have_ seen that horror perpetrated in real Python code (doesn't break
any library, but slows function execution down by 10 times w/o any real
advantage wrt dicts or bunch usage, and is a bug-prone piece too...).
Alex

Jul 18 '05 #62

Steven Bethard <st************@gmail.com> wrote:

My point here is that I think in most code, even when people do a bunch of
bit-twiddling, they have a single underlying structure in mind, and therefore
you see them treat the bits as one of two things: (1) The sequence of bits, i.e.
the untyped memory block, or (2) the intended structure. IMHO, an example of
taking advantage of weak-typing would be a case where you treat the bits as
three different things: the sequence of bits, and two (mutually exclusive)
intended structures.

One word: union

Jul 18 '05 #63

Alex Martelli <aleaxit <at> yahoo.com> writes:

I apologize if I have given the impression of being upset.
No problem -- my mistake for misinterpreting you. I'm just sensitive to these
kind of things because I know I've previously miscommunicated, and
unintentionally got people upset before (you being one of them). ;)
I am, in a
way, I guess -- astonished and nonplusses, as if somebody asked me to
justify the existence of bread -- not of some exotic food, mind you, but
of the most obvious, elementary, fundamental substance of earthly
sustenance (in my culture, and many others around it).
Yeah, this goes to the heart of the misunderstanding. I'm not asking anyone to
justify the _existence_ of weak-typing. Weak-typing is a direct result of a
language's support for untyped (bit/byte) data. I agree 100% that this sort of
data is not only useful, but often essential in any low-level (e.g. OS, hardware
driver, etc.) code.
So, we have an area
of 8 bytes in memory which we need to be able to treat as:
8 bytes, for I/O purposes, say;
a float, to feed it to some specialized register, say;
a bit indicating sign plus 15 for mantissa plus 48 for significand,
or the like, to perform masking and shifting thereof in SW -- a
structure of three odd-bit-sized integers juxtaposed;
As a quick refresher, I quote myself in what I was looking for:
"taking advantage of weak-typing would be a case where you treat the bits as
three different things: the sequence of bits, and two (mutually exclusive)
intended structures."

My response to this example is that your two intended structures are not
mutually exclusive. Yes, you have to do some bit-twiddling, but only because
your float struct doesn't have get_sign, get_mantissa and get_significand
methods. ;) You're still dealing with the same representation, not converting
to a different type. You're just addressing a lower level part of the
representation.

I can see the point though: at least in most of the languages I'm familiar with,
float is declared as a type while there's no subtype of float that specifies the
sign, mantissa and significand.

(Oh, and by the way, in case you really were wondering, they still do teach
float representations, even in computer science (as opposed to computer
engineering), or at least they did through 1999.)
Another example: we're going to send a controlblock of 64 bytes to some
HW peripheral, and get it back perhaps with some mods -- a typical
control/status arrangement. Depending on the top 2 (or in some case 4)
bytes' value, the structure may need to be interpreted in several
possible ways, in terms of juxtaposition of characters, halfwords and
longwords. Again, the driver responsible for talking with this
peripheral needs to be able to superimpose on the 64 bytes any of
several possible C-level struct's -- the cleanest way to do this would
appear to be pointer-casting, though unions would (as usual, of course)
be essentially equivalent.

Is the interpretation of the controlblock uniquely defined by the top 2 or 4
bytes, or are there some values for the top 2 or 4 bytes for which I have to
apply two different interpretations (C-level structs) to the same sequence of
bits?

If the top 2 or 4 bytes uniquely define the structs, then I would just say
you're just going back and forth between a typed structure and its untyped
representation. If the top 2 or 4 bytes can specify multiple interpretations
for the same sequence of bits, then this is the example I was looking for. =)

Steve

Jul 18 '05 #64

Michael Hobbs <mike <at> hobbshouse.org> writes:

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]

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!

Thanks,

Steve

Jul 18 '05 #65

Steven Bethard <st************@gmail.com> wrote:
...

Yeah, this goes to the heart of the misunderstanding. I'm not asking
anyone to justify the _existence_ of weak-typing. Weak-typing is a direct
result of a language's support for untyped (bit/byte) data. I agree 100%
that this sort of data is not only useful, but often essential in any
low-level (e.g. OS, hardware driver, etc.) code.
But so is the ability to get at the same bits/bytes in structured ways.

So, we have an area

of 8 bytes in memory which we need to be able to treat as:
8 bytes, for I/O purposes, say;
a float, to feed it to some specialized register, say;
a bit indicating sign plus 15 for mantissa plus 48 for significand,
or the like, to perform masking and shifting thereof in SW -- a
structure of three odd-bit-sized integers juxtaposed;

As a quick refresher, I quote myself in what I was looking for: "taking
advantage of weak-typing would be a case where you treat the bits as three
different things: the sequence of bits, and two (mutually exclusive)
intended structures."

My response to this example is that your two intended structures are not
mutually exclusive. Yes, you have to do some bit-twiddling, but only
because your float struct doesn't have get_sign, get_mantissa and
get_significand methods. ;) You're still dealing with the same
representation, not converting to a different type. You're just
addressing a lower level part of the representation.

What do you mean by "mutually exclusive"? "Never useful at the same
time"? You're asking for an example of things never useful at the same
time that are useful at the same time?!

The struct type with so many bits being signs, exponent, significands,
IS a distinct type from double-precision float -- it's the
representation of the latter according to some standard. To multiply by
0.1 I have to have a float, to 'get the N-bit integer that gives the
exponent shifted right by 3' I have to have that struct type. They're
totally distinct (not "mutually exclusive" because they ARE useful as
ways to look at the same bitbunch at the same time, of course) types,
ways to analyze or interpret the same bunch of bits (apart from the
untyped representation where I can do binary I/O with them, too).

I can see the point though: at least in most of the languages I'm familiar
with, float is declared as a type while there's no subtype of float that
specifies the sign, mantissa and significand.
Right. To get at the bitfields, you use weaktyping instead.

Another example: we're going to send a controlblock of 64 bytes to some
HW peripheral, and get it back perhaps with some mods -- a typical
control/status arrangement. Depending on the top 2 (or in some case 4)
bytes' value, the structure may need to be interpreted in several
possible ways, in terms of juxtaposition of characters, halfwords and
longwords. Again, the driver responsible for talking with this
peripheral needs to be able to superimpose on the 64 bytes any of
several possible C-level struct's -- the cleanest way to do this would
appear to be pointer-casting, though unions would (as usual, of course)
be essentially equivalent.

Is the interpretation of the controlblock uniquely defined by the top 2 or 4
bytes, or are there some values for the top 2 or 4 bytes for which I have to
apply two different interpretations (C-level structs) to the same sequence of
bits?

In the HW I was thinking of, the former is the case.
If the top 2 or 4 bytes uniquely define the structs, then I would just say
you're just going back and forth between a typed structure and its untyped
representation. If the top 2 or 4 bytes can specify multiple interpretations
for the same sequence of bits, then this is the example I was looking for. =)

I need to examine the top bytes of the block as the HW returned it, in
some cases, to know what struct type is most useful to interpret the
bunch of bits. There is typically only one type (besides 'just a bunch
of 64 bytes') that it useful at _one_ given time. But weak typing does
not require parallel processing without locks -- only if two independent
threads of controls were looking at the same bits concurrently from two
separate processors would saying "at ONE time" make sense... true and
unfettered concurrent access...

As for two different interpretations of the same bits being useful (not
"at the same time"), consider a 16-bit field that can be seen as one
16-bit word or two 8-bit bytes. In the former case, '0' means the whole
operation concluded successfully, any non-0 means problems were
encountered. So, a piece of code that just needs a pass/nonpass filter
on the operation is best advised to tread that field as a 16-bit word,
so it can test it for == or != 0 atomically.

At a deeper level, one byte indicates possible problems of one kind (say
ones "intrinsic" to the procedure/operation in question), another
indicates possible problems of a different kind (say ones "extrinsic" to
the procedure per se, but caused by preemption, power failures, etc).
Unix return-status values aren't too far away from this. If you need
accurate diagnosis of what went wrong, seeing the same field as two
8-bit bytes is handier (assuming you can get some kind of lock in that
case, since you are then dealing with nonatomic testing).

You could see a test such as "if x->field16 == 0:" as a weird shorthand
for "if x->field8_a == 0 and x->field8_b == 0:", but depending on
considerations of atomicity it might not even be.
Another example where the same sequence of bits may be usefully
interpreted in more ways at the same time: given a string of bytes which
encodes some unicode text in utf-8 it's clearly useful to consider it as
such, parsing it left to right byte by byte to find the unicode chars
being encoded and display the proper glyphs, etc. But I may also want
to walk the same area of memory as a sequence of 64-bit words to compute
a simple checksum to ensure data integrity (as well as the usual need
for 'untyped' bytescan for I/O). Or, say I don't know whether the
incoming data were utf-8 or utf-16; by walking over them in both 1-byte
(utf-8) and 2-byte units I may well be able to get strong heuristic
indications of which of the two encodings was in use. Similar
heuristics are sometimes very useful even in determining whether a bunch
of 4-byte words from a record are floats or ints -- as long, of course,
as you CAN walk them both ways and compare strangeness-indicators. If
you even need to recover old data from datasets whose details were lost,
you'll find that out for yourself.
Alex

Jul 18 '05 #66

Christophe Cavalaria

Michael Hobbs wrote:

Steven Bethard <st************@gmail.com> wrote:
My point here is that I think in most code, even when people do a bunch
of bit-twiddling, they have a single underlying structure in mind, and
therefore you see them treat the bits as one of two things: (1) The
sequence of bits, i.e.
the untyped memory block, or (2) the intended structure. IMHO, an
example of taking advantage of weak-typing would be a case where you
treat the bits as three different things: the sequence of bits, and two
(mutually exclusive) intended structures.

One word: union

Note that in the C standard, writing to part A of an union and reading from
part B is UB : undefined behavior and so it should *not* be used.

Jul 18 '05 #67

Alex Martelli <aleaxit <at> yahoo.com> writes:

[snip example decomposing float representation into mantissa, etc.] [snip example determining struct type from first few bytes] [snip example decomposing 16 bit error code into two 8 bit error codes]

[snip example determining utf-8 or utf-16 by trying byte stream as both]

Thanks for the examples!

I'm not quite convinced by the decomposition examples or the struct type
example, but the UTF example is definitely convincing. I can imagine that you
could extend this type of example to any case where you didn't know the actual
type of a struct. Given this situation, you could try treating the bytes as
each of the possible struct types, and see (heuristically or perhaps with a
machine learning approach) which struct type is most appropriate.

This definitely meets my criterion of treating the same set of bytes as two
different structures, and it's even useful! =) Thanks!

Steve

Jul 18 '05 #68

Steven Bethard <st************@gmail.com> wrote:

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!

This example is a little weak, but may be sufficient. The in_addr
structure used for sockets usually uses a union to provide different
views to the underlying 32-bit address. You can access the address
as 4 8-bit values, 2 16-bit values, or 1 32-bit value. Most code
these days only use the 4 8-bit representation, but the interface is
there.

Another possible example comes from the Windows API. Some of the
functions take an arbitrary length structure. If you want to make a
simple call to the function, you pass a small structure. If you
want to make a more complex call to the function, you pass a larger
structure that has more fields tacked on to the end. Usually, the
first field in the structure is an int that specifies how large the
structure is. It is used as sort of a crude version of OO in C.

I'm not sure if these are the kinds of examples you're looking for.
I don't know how anyone would be able to use a sequence of bytes as
two types of data at once. There is almost always some sort of
indicator that specifies how to interpret the bytes; otherwise, it
is just garbage.

-- Mike

Jul 18 '05 #69

Steven Bethard wrote:

Michael Hobbs <mike <at> hobbshouse.org> writes:

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.
--
Regards,

Diez B. Roggisch

Jul 18 '05 #70

Greg Ewing

Diez B. Roggisch wrote:

I can remeber abusing 32bit pointers in 68k processors by
altering the most-significant byte.

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...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Jul 18 '05 #71

Mike Meyer

Steven Bethard <st************@gmail.com> writes:

JCM <joshway_without_spam <at> myway.com> writes:
> Definition 1 is the definition most commonly used in Programming
> Languages literature.... 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.

Assembly language. The types of values are implied by what
instructions you use.

I'm sure some people would argue that assembly language is untyped (not
statically or dynamically typed) and that the operations are defined on bits,
but this is definitely the best example I've seen. Thanks!

The previously mentioned BCPL has the exact same property. For that
matter, early versions of C used to allow it to a large degree. I've
actually compiled programs written as "char *main = { ... }".

To me, a dynamically typed language is one where objects - rather than
variables - have a type attached.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Jul 18 '05 #72

Mike Meyer

Steven Bethard <st************@gmail.com> writes:

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Jul 18 '05 #73

Steven Bethard <st************@gmail.com> wrote:

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.

Jul 18 '05 #74

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote:

Diez B. Roggisch wrote:
I can remeber abusing 32bit pointers in 68k processors by
altering the most-significant byte.

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

Jul 18 '05 #75

Steven Bethard <st************@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...

Gabriel Zachmann writes:

would sort of a summary of this thread be of any help?

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*
--
CARL BANKS

Jul 18 '05 #76

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) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

Jul 18 '05 #77

Dave Benjamin

In article <cm*************@news.t-online.com>, Diez B. Roggisch wrote:

Steven Bethard wrote:
Michael Hobbs <mike <at> hobbshouse.org> writes:

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.

--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"talking about music is like dancing about architecture."

Jul 18 '05 #78

Stefan Axelsson

Carl Banks wrote:

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.
-----------------------------------------------------------------------

I'd say that this horse is well and truly dead...

Stefan,
--
Stefan Axelsson (email at http://www.cs.chalmers.se/~sax)

Jul 18 '05 #79

Greg Ewing

Carl Banks wrote:

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...)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Jul 18 '05 #80

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) |
+-------------------------------------------------------------------------+
| za**@cs.uni-bonn.de __@/' www.gabrielzachmann.org |
\-------------------------------------------------------------------------/

Jul 18 '05 #81

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote in message news:<2v*************@uni-berlin.de>...

Carl Banks wrote:
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

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,
--
CARL BANKS

Jul 18 '05 #82

Martin Maney

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote:

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?

--
Among the greater ironies of the computer age is the fact that
information is cheap and accessible, and so it is no longer very valuable.
What is valuable is what one does with it.
And human imagination cannot be mechanized. -- the New York Times

Jul 18 '05 #83

JCM

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote:

Carl Banks wrote:
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...)

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

Jul 18 '05 #84

Greg Ewing

JCM wrote:

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...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

Jul 18 '05 #85

Tim Hoffman

Greg Ewing wrote:

JCM wrote:
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...

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

Jul 18 '05 #86

JCM <jo******************@myway.com> wrote:

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote:
Carl Banks wrote:
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...)

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

Jul 18 '05 #87

Andrew Dalke

Tim Hoffman wrote:

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
da***@dalkescientific.com

Jul 18 '05 #88

mi**@hobbshouse.org (Michael Hobbs) wrote in message news:<10*************@corp.supernews.com>...

JCM <jo******************@myway.com> wrote:
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".

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.
--
CARL BANKS

Jul 18 '05 #89

Jeff Shannon

Carl Banks wrote:

mi**@hobbshouse.org (Michael Hobbs) wrote in message news:<10*************@corp.supernews.com>...

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

Jul 18 '05 #90

Jeff Shannon <je**@ccvcorp.com> wrote in message news:<10*************@corp.supernews.com>...

Carl Banks wrote:
mi**@hobbshouse.org (Michael Hobbs) wrote in message news:<10*************@corp.supernews.com>...

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.
--
CARL BANKS

Jul 18 '05 #91

Jeff Shannon

Carl Banks wrote:

Jeff Shannon <je**@ccvcorp.com> wrote in message news:<10*************@corp.supernews.com>...

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.

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

Jul 18 '05 #92

Jeff Shannon <je**@ccvcorp.com> wrote in message news:<10*************@corp.supernews.com>...

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.

Testy? What, do you expect me to automatically give you credit for
having paid attention to some decades-ago schooling unrelated to you
field of work, even though I've never met or spoken to you?

Anyways, although you've claimed "rigid" is very specific in meaning,
based on some dictionary entries, I really don't see any arguments
that tried to refute my claim that "rigid" could be easily taken to
mean inability to reinterpret bits, or less easily to mean static
typing. Conversely, I also didn't see any good examples of how
"solid" could easily mean something else. (I thought the idea that it
could refer to data hiding quite a stretch, although not totally off
the wall. Nevertheless, I would say "rigid" is vastly more applicable
to interpreting bits than "solid" is to data hiding.)

I would like to see your ideas and thoughts about how applicable
"solid" and "rigid" are specifically to typing. I've already stated
my thoughts about this. What objections to you have those points?
--
CARL BANKS

Jul 18 '05 #93

Carl Banks <im*****@aerojockey.com> wrote:

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

Hmmmm... I like to bank with a solid bank --> they won't go bankrupt
tomorrow. Hopefully they're not rigid --> can accomodate to changing
circumstances. And the bank's officers have years of solid experience
at their jobs, and deserve my solid trust...
Alex

Jul 18 '05 #94