Types, types: static vs. dynamic -- classification 
Author Message
 Types, types: static vs. dynamic -- classification


Quote:

>What do you mean by dynamic polymorphism?
>C++ is _not_ dynamically typed and therefore guarantees, that no type error
>occurs at run time in contrast to Smalltalk, which _is_ dynamically typed.

Can someone define just what a TYPE is??  

Dumb-ole-me always thought that variables had a 'type' to tell the
compiler what the bits meant (and how many bits there were).
Since Smalltalk variables always hold the same thing, an object,
then they always had the same type (object) and it wasn't necessary
to say anything explicit.

And dumb-ole-me thought that objects were a whole different kind
of thing in which the data described itself and types were
unnecessary baggage from the past.

Yet, I keep hearing about all this dynamic-type stuff, and
type-inheritence, and other puzzling things.

Can someone explain it to me?

And BTW, isn't it a 'type error' when a pointer exceeds the length
of a string and munges through the disk allocation tables? (Or is
that, uh, ...)

Dave

__________________________________
David N. Smith


IBM T J Watson Research Center
Hawthorne, NY
__________________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.



Wed, 08 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification


:
: >What do you mean by dynamic polymorphism?

My definition is substitution of program's parts during run time.  See
"The Beauty and Power of C++" by me in the May 1995 Object magazine for
one source of more information.

Elliott



Wed, 08 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

>: >What do you mean by dynamic polymorphism?

>My definition is substitution of program's parts during run time.  See
>"The Beauty and Power of C++" by me in the May 1995 Object magazine for
>one source of more information.

Polymorphism means, literally, multiple meanings.

So, I suppose the definitions are:

Static Polymorphism

   Multiple meanings resolved statically (ie, without execution of
   the program being of any assistance).

Dynamic Polymorphism

   Multiple meanings resolved dynamically (ie, with execution of
   the program assisting in the determination of which meaning to
   select.)

Dave

__________________________________
David N. Smith


IBM T J Watson Research Center
Hawthorne, NY
__________________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.



Thu, 09 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification


Arne> What do you mean by dynamic polymorphism?  C++ is _not_
Arne> dynamically typed and therefore guarantees, that no type error
Arne> occurs at run time

It is dynamically typed, in the sense that the type of a variable can be
"different" from that of the value it refers to, if it is a pointer (a
variable of type T* can denote values of all types derived from
T). "type" errors "cannot" occur at runtime in C++ because there are
complex rules outlawing them, not because all types are known at
compiletime.

Arne> in contrast to Smalltalk, which _is_ dynamically typed.

David> Can someone define just what a TYPE is??  

A lot of people have tried. To me it is a set of operations, and any
value to which those operations can be meaningfully applied "belongs" to
that type.

David> Dumb-ole-me always thought that variables had a 'type' to tell
David> the compiler what the bits meant (and how many bits there were).

This seems a terrible way to start investigating the notion of type: for
what is really interesting is that _values_, whether denoted by
variables or by other values, "have" a type. Also it may be the source
of confusion to regard as a value "having" a type, as opposed to
"belonging" to a type.

What happens in any languages is that values have a (compiletime or
runtime) *tag* that identifies a type (for it is much easier to have
each value point to its "type" than viceversa), but this is an
unfortunate if useful implementation hack (for it makes rather harder to
think of values as belonging to several types at the same time, which is
instead an absolutely important notion).

David> Since Smalltalk variables always hold the same thing, an object,

This is rather imprecise: Smalltalk variables "hold" object
ids/pointers/references/..., not objects.

David> then they always had the same type (object) and it wasn't
David> necessary to say anything explicit.

Let's rephrase this: they always have the type "pointer to class
Object", and since all classes derive from class Object, ...

The main difference between C++ and Smalltalk is that C++ does not by
default allow downcasting, while Smalltalk does it implicitly.

David> And dumb-ole-me thought that objects were a whole different kind
David> of thing in which the data described itself and types were
David> unnecessary baggage from the past.

It is a curious notion that objects are a whole different kind of thing
in which the data described itself. This is a description that reminds
me more of frames and semantics networks and KR than of object
technology (but then there are those that there is no difference). To
some objects are just values in a programming system based on language
support of ADTs/classes/...

David> Yet, I keep hearing about all this dynamic-type stuff, and
David> type-inheritence, and other puzzling things.

David> Can someone explain it to me?



Fri, 10 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

: Polymorphism means, literally, multiple meanings.

The word is borrowed from old Greek and means 'multiple forms'.
When for instance a chemical compound transforms into crystals
there may be multiple crystal forms developing.

Transferring this original meaning into object orientation
I like the following interpretation:

Polymorphism of an entity, means that this
entity can take on different forms over its lifetime.
If that entity is for instance a variable this means
that this variable can stand for objects of different
types over its lifetime (one object and object type at a time).

These forms (or types) are of course associated with behavior
or meaning if you like, and we arrived at the following:

: So, I suppose the definitions are:

: Static Polymorphism

:    Multiple meanings resolved statically (ie, without execution of
:    the program being of any assistance).

: Dynamic Polymorphism

:    Multiple meanings resolved dynamically (ie, with execution of
:    the program assisting in the determination of which meaning to
:    select.)

--



Sat, 11 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

>Static Polymorphism

>   Multiple meanings resolved statically (ie, without execution of
>   the program being of any assistance).

>Dynamic Polymorphism

>   Multiple meanings resolved dynamically (ie, with execution of
>   the program assisting in the determination of which meaning to
>   select.)

In which case C++ polymorphism is dynamnic, and the only language
with static polymorphism is Standard ML. Is this what you intended ?
I have never hear of static and dynamic polymorphism before, I have
heard of static and dynamic typing, but that is different.

---
     1



Sun, 12 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:
>Not in 'conventional languages' where values are a handfull of
>bits fully dependent on what you tell the compiler they mean.
>There isn't any kind of tag on words in modern hardware.

There are still tagged hardware architectures around, and some
are far from archaic.  Also, as you allude to below, there is nothing
to prevent software from treating the bits as tags.
Quote:
>....Smalltalk variables hold object pointers. Period. (Some object
>pointers have a value encoded directly, and are tagged, ....



Sun, 12 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

:
: >
: >Static Polymorphism
: >
: >   Multiple meanings resolved statically (ie, without execution of
: >   the program being of any assistance).
: >
: >Dynamic Polymorphism
: >
: >   Multiple meanings resolved dynamically (ie, with execution of
: >   the program assisting in the determination of which meaning to
: >   select.)
:
: In which case C++ polymorphism is dynamnic, and the only language
: with static polymorphism is Standard ML.

How about function name overloading in C++?  The call is often binded at
compile.

Elliott



Sun, 12 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

>>Static Polymorphism

>>   Multiple meanings resolved statically (ie, without execution of
>>   the program being of any assistance).

>>Dynamic Polymorphism

>>   Multiple meanings resolved dynamically (ie, with execution of
>>   the program assisting in the determination of which meaning to
>>   select.)

>In which case C++ polymorphism is dynamnic, and the only language
>with static polymorphism is Standard ML. Is this what you intended ?
>I have never hear of static and dynamic polymorphism before, I have
>heard of static and dynamic typing, but that is different.

Me either! That's why I posted these definitions. I hoped for some
discussion or confirmation from someone who DID know what the terms
mean. BTW, ignoring virtual functions, I thought C++ was entirely
static though??  How is it dynamic?

Dave

--- just trying to make sense of it all ---

__________________________________
David N. Smith


IBM T J Watson Research Center
Hawthorne, NY
__________________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.



Mon, 13 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

>In most languages used in the past twenty years values are *implemented*
>as untyped bitstrings, but that's just the *compiler's* business: the
>*language* defines values as typed entities (save for modest exceptions
>like the ability to do bitwise operations on integral types in C).

Beep. Sorry, this is wrong. C defines the integer and character types as
being bit strings, and programmers assume even more than is actually defined,
and this is normally considered a reasonable practice. It applies much
less to C++, but to do lots of things in C you *need* to know how the
basic types are implemented, as 32, 16 and 8 bit bit strings.

Quote:
>Perhaps you should really revise your Smalltalk, for in no way in
>Smalltalk "data describes itself" and "types were unneccessary baggage
>from the past". For in Smalltalk data are described by classes (which
>implement/are types) not by themselves, and Smalltalk is a strongly (if
>latently) typed language. Again you seem to have forgotten the small
>detail of the 'class' method of the Object class, which returns the,
>ahem, "type" of a data object.

Smalltalk objects certainly do carry a 'tag' stating their class, all
objects have this and it is always right. However to call this a type
and to say Smalltalk is 'strongly typed' is to use a very unusual
definition of type.

To say that a language is typed, as I see it, it must perform some
checks on types, either at run time or at compile time.  To call a
language strongly typed it must perform these checks at compile
time in order to remove the possibility of some kind of error
arising at run-time (modern C and C++ ensure that values are not
unwittingly treated as being the wrong type, Standard ML ensures that
no operation is ever performed on a value of the wrong type. etc).

Smalltalk does none of this, unless you count 'message not understood'
as a limited form of dynamic type checking.

Simon
--
     1



Sun, 19 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification


   >In most languages used in the past twenty years values are *implemented*
   >as untyped bitstrings, but that's just the *compiler's* business: the
   >*language* defines values as typed entities (save for modest exceptions
   >like the ability to do bitwise operations on integral types in C).

   Beep. Sorry, this is wrong. C defines the integer and character types as
   being bit strings, and programmers assume even more than is actually defined,
   and this is normally considered a reasonable practice. It applies much
   less to C++, but to do lots of things in C you *need* to know how the
   basic types are implemented, as 32, 16 and 8 bit bit strings.

C and C++ are not ``most languages''; they are at most 2 languages.

   >Perhaps you should really revise your Smalltalk, for in no way in
   >Smalltalk "data describes itself" and "types were unneccessary baggage
   >from the past". For in Smalltalk data are described by classes (which
   >implement/are types) not by themselves, and Smalltalk is a strongly (if
   >latently) typed language. Again you seem to have forgotten the small
   >detail of the 'class' method of the Object class, which returns the,
   >ahem, "type" of a data object.

   Smalltalk objects certainly do carry a 'tag' stating their class, all
   objects have this and it is always right. However to call this a type
   and to say Smalltalk is 'strongly typed' is to use a very unusual
   definition of type.

It doesn't seem unusual to *me*; not necessarily *right*, but defensible.

   To say that a language is typed, as I see it, it must perform some
   checks on types, either at run time or at compile time.  To call a
   language strongly typed it must perform these checks at compile
   time

Terminology wars: that's *static* typing, not *strong* typing.

   in order to remove the possibility of some kind of error
   arising at run-time (modern C and C++ ensure that values are not
   unwittingly treated as being the wrong type, Standard ML ensures that
   no operation is ever performed on a value of the wrong type. etc).

   Smalltalk does none of this, unless you count 'message not understood'
   as a limited form of dynamic type checking.

Whis is exactly what it is; ``you wanted to this to that, but you can't,
so there'', rather than ``you want to do this to that? fine ... *I* won't
be responsible for the consequences''.
--

Regards,    | ``"I can't suit myself," said Weinbaum, a little petulantly.
Kers.       | "I work for the Government".'' - Blish, "The Quincunx of Time".



Sun, 19 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:
>>> On 1 Nov 1995 16:21:10 GMT, "Stefan Monnier"



Simon> Smalltalk objects certainly do carry a 'tag' stating their class,
Simon> all objects have this and it is always right. However to call
Simon> this a type and to say Smalltalk is 'strongly typed' is to use a
Simon> very unusual definition of type.

In a sense yes: the confusion between 'strongly typed' and
'manifestly/statically typed' is indeed usual; but while common at least
some people like Stefan don't make it, unusually, so perhaps everybody
could stop making it:

Stefan> Strongly typed generally means that the language will prevent
Stefan> you from adding the color of your socks to the address of your
Stefan> boy-friend.

Stefan> Statically typed means that the type checks are designed so that
Stefan> they can be done at compile time (or somehing to that effect
Stefan> like: types are attached to variables and the language enforces
Stefan> that a variable of type A will always hold a value of type A).

This is unusually better known though as 'manifest' typing, because it
need not be 'static': for example in the case of 'T *; in C++, the
actual type of the value denoted can be a subclass of 'T', yet it is
manifest (because of the declaration) that it must be a subclass of only
'T' (and therefore the compiler will only let you apply to it operators
defined for T only). This is a border case though, and it can be argued
that this is not really manifest typing.

Stefan> C is statically typed, but not strongly typed.

Please note: Stefan writes 'C', not 'ANSI C': for 'ANSI C' *is* strongly
typed, for all cases of type punning are explicitly outlawed, even if
the compiler will not check. In 'C' the type system is weak, in that by
way of casting or using union overlays one can violate the type system
(almost) "legally".

A better example would be BCPL, the precursor^-2 of C: in BCPL there are
is only one "type", 'word', and then one can apply any operation to any
value, i.e. not type checking at all is done, just like in (most)
assemblers (note that some assemblers instead have, at least in part,
both manifest and strong typing, e.g. Microsoft's ASM).

Stefan> Lisp is strongly typed but not statically typed.

Simon> Smalltalk does none of this, unless you count 'message not
Simon> understood' as a limited form of dynamic type checking.

Well, it is indeed:

Stefan> When your lisp tells you "error: can't take the car of 12
Stefan> because it's not a list" you do consider it as a type check,
Stefan> right ? Now isn't this exactly the same as if you lisp had told
Stefan> you "12 doesn't understand the car message" ?

Even more interesting: there are variants of Smalltalk, like Johnson's
"Typed Smalltalk", in which an analysis is made of operation-operand
usage patterns, and in which variables are then, if possible, manifestly
typed, for optimization purposes.



Sun, 19 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

> >|> The majority of static OO langauges including C++, Eiffel, Sather,
> >|> Beta, Modula-3, Ada95, etc, use polymorphism in the case which
> >|> I described as dynamically typed variables or parameters.

> >Actually, C++ has both static and dynamic polymorphism.  The static
> >polymorphism is implemented using templates, and the dynamic using
> >virtual functions.  Thus, for example, the STL function ``sort'' is
> >polymorphic, although the polymorphism is resolved at compile time
> >(staticly).

What you call static polymorphism it is not what some people used to call
parametrized types ?
It sounds strange for me separete static from dynamic polymorphism.

Cheers.
Christiano de Oliveira Braga

Pontificia Universidade Catolica
Departamento de Informatica
Laboratorio IBM de Desenvolvimento de Software
http://www.lids.puc-rio.br/~cbraga



Sun, 19 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

: >What do you mean by dynamic polymorphism?
: >C++ is _not_ dynamically typed and therefore guarantees, that no type error
: >occurs at run time in contrast to Smalltalk, which _is_ dynamically typed.

Subclass sub;
....
....
void* po=⊂
(Superclass*)po-> method();

Dom
--
_____________________________________________________________________________


  Board Systems                          Desk/voicemail: +44(0) 1202 850951
  Wimborne, Dorset,                      Site reception: +44(0) 1202 850850
  England, BH21 7PP                      Fax:            +44(0) 1202 850988
_____________________________________________________________________________



Mon, 20 Apr 1998 03:00:00 GMT  
 Types, types: static vs. dynamic -- classification

Quote:

> ...

(This thread illustrates the problems every time a discussion of
Typing In Smalltalk occurs.)

I contend that Smalltalk HAS NO CONCEPT OF TYPE.

'Conventional Languages'
------------------------

Popular languages that most programmers are familiar with (C, C++,
COBOL, fortran, PL/I, and Pascal come to mind) have types. (I'm
leaving out research and specialized languages on purpose.)

A variable, say zot, cannot be declared without specifying,
explicitly or implicitly (by some default rules) what it 'holds'.
This is done using language keywords as in C:

    long int zot;
    float flot;

The variable zot holds (or describes or references or whatever)
some memory. On many machines this will be 32 bits of memory
aligned in some way. Since the type is int, the compiler will
generate code that treats these bits as an integer.

The variable flot holds (or describes or references or whatever)
some memory. This will be 32 bits of memory aligned in some way.
Since the 'type' is float, the compiler will generate code that
treats these bits as a floating point number.

The bits are otherwise the same. There is no distinction between
memory locations that hold integers of 32 bits length and floating
point numbers of 32 bits length. (And using some well-defined
constructions, C programmers can access the same memory 'cell' with
variables of various types; FORTRAN programmers can, too, even more
easily with equivalence declarations.)

Thus, the typing is in the language, the language has to know at
compile time what type a variable is, and it generates code using
that knowledge. There are no tags on the data saying that 'this is
an integer' or 'this is a float'.

Thus, types are a characteristic of variables which aid the
compiler in producing proper code.

Smalltalk
---------

Smalltalk has variables but no language keywords to specify what
the variable 'holds'. Variables are declared by listing their
names:

   | zot flot |

The variables zot and flot can 'hold' some objects. (Let us please
not enter into the discussion about pointers again -- we all know
that Smalltalk variables actually hold pointers to objects and that
the language does the dereferencing for us.)

So what are the types of zot and flot? There aren't any. (One could
say that they have the type 'object' just as well, but does a
language with one type have types?)

Now, let's do this:

   | zot flot |
   zot  := 23.
   flot := 23.45.

What are the types of the variables zot and flot? Does zot now have
the type 'Integer' and flot the type 'Float'?

I contend that they have not changed one iota. They didn't have a
type before and they don't now. Assigning a value to a variable in
Smalltalk does not change the type of the variable, at least
without doing great damage to the commonly held view of what 'type'
means.

Now, consider:

   | zot flot |
   zot  := 23.
   flot := 23.45.
   flot := flot asInteger

Has flot changed its type yet again?

Consider this:

holdsNil: aCollection
    aCollection
        do: [ :element |
            element = nil
                ifTrue: [ ^ true ] ].
    ^ false

What is the type of aCollection? Does it change its 'type'
everytime that it is called? In Smalltalk, aCollection can be ANY
object that responds to do: by invoking a block and passing one
parameter to it. It doesn't have to be a collection of any kind.

Saying that all types derive from type Object misses the point
entirely. There are no types to derive from.

Smalltalk inheritence is not a type inheritence but an
implementation sharing inheritence.

Smalltalk values ARE tagged. The variable aCollection is self
describing. The compiler can generate code without having any type
information -- the only operations are message sends and assigns.

There are no types.

Smalltalk IS different.

Dave

Note that Smalltalk compilers are free to cheat like mad. It all
is in line with Peter Deutsch's observation that implementing a
language like Smalltalk efficiently requires the implementor to
cheat, but that's okay as long as you don't get caught. If the
compiler wants to play games with variables that might hold
integers, it can -- so long as it doesn't break the language
semantics. And all Smalltalk systems DO play games with integers.
All of which has nothing to do with the semantics of Smalltalk
or types IN the language.

__________________________________
David N. Smith


IBM T J Watson Research Center
Hawthorne, NY
__________________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.



Mon, 20 Apr 1998 03:00:00 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Types, types: static vs. dynamic -- classification

2. Types, types: static vs. dynamic -- classification

3. Types, types: static vs. dynamic --

4. Flying With Python (Strong versus Weak Typing) [actually, Static vs Dynamic typing]

5. Static vs Dynamic Typing: Effects on Productivity?

6. Dynamic vs. static type checking

7. Static vs Dynamic Typing: Effects on Productivity?

8. Static vs Dynamic Typing: Effects on Productivity?

9. Static vs Dynamic Typing: Effects on Productivity?

10. Dynamic vs static typing: impact on modelling capabilities

11. static vs dynamic/soft typing

12. static vs. dynamic typing (again, again)

 

 
Powered by phpBB® Forum Software