Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.object
Subject: Re: A Hard Problem for Static Type Systems
Message-ID: <52387@nigel.ee.udel.edu>
Date: 2 May 91 00:20:35 GMT
References: <556@eiffel.UUCP> <52166@nigel.ee.udel.edu> <1991May1.143831.2065@maths.nott.ac.uk>
Sender: usenet@ee.udel.edu
Followup-To: poster
Organization: University of Delaware
Lines: 82
Nntp-Posting-Host: estelle.ee.udel.edu

In article <1991May1.143831.2065@maths.nott.ac.uk> anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
>In article <52166@nigel.ee.udel.edu> new@ee.udel.edu (Darren New) writes:
>>Besides, I still haven't seen a good example of how to do hetrogeneous
>>lists in a statically-typed language.

(a) gives you a bunch of homogenous lists.

(b) gives you a list of unions (which can only contain types you consider when
    you write the program).

>(c) Given a collection of ways of constructing types, say "array of",
>    "pointer to", "procedure with parameters ... returning ...", etc.,
>    there is no difficulty [in suitable languages!] in constructing an
>    ADT (perhaps some tree structure) which represents arbitrary types
>    and building lists of this ADT (and/or of instantiated objects of
>    such types).  Compilers do this all the time.

Getting closer.  However, you have to then run this through the
compiler.  (Hermes can let you do this.)  Or are you talking about
something like XDR or a routine to do ASN.1/BER encoding or something?
Then you are implementing dynamic typing in order to obtain hetro
lists.

>(d) Given a generic pointer, in languages that assume rightly or
>    wrongly that all pointers are the same "shape", there is no
>    difficulty in building a list of pointers to arbitrary objects.
>    Storage allocators do this all the time.

But doing this makes it difficult to actually *do* something with
the values you are pointing to.

>	Are you thinking of something else?  Or is one of (a-d) what
>you are after?

I think the canonical example (for me) is something like a resource manager.
I want to be able to write a routine (once) and compile it (once) at
the beginning of my work. This routine should accept pairs of
<name, value> where the value may be anything the language can handle.
It should be able to add and find and remove tuples, and it should be
able to iterate through the list, handing me each tuple (for example,
to find out the total number of bytes used by values). In case (c),
you have to write code for each type to break it into the values you are 
looking for, interpret the tags, etc.  In case (d), you have to already
know the type of the object associated with each name before you can
do anything with it (such as find it's size) or else it turns into case (c).

>	[I have no axe to grind on the general static/dynamic debate.
>Dynamic typing is often more convenient, but it is, I still maintain,
>*necessary* only when you, the programmer, don't know what types of
>objects your program is going to have to deal with or what operations
>are going to be effected on them.  

Right.

>That situation might be acceptable
>for a quick prototype, but not for a finished system.  

Here I must disagree.  Building libraries for other people to use, and
building these libraries such that the library can evolve without
invalidating programs built with previous versions of the library and
vica versa, is an important use for dynamically-typed systems.  I don't
think that your (d) is as safe as a dynamic type system.

I'm starting to think that "dynamic typing" might be somewhat akin to
"object oriented programming" in the sense that it is more a
organization/management technique than an actual programming language
issue.  Just like you can do object-oriented programming in COBOL (but
it isn't very pretty), you can "do" dynamic typing in a static language
(but it isn't very pretty).  If you knew at the start exactly how the
program would work, knew all the programs it would ever have to
interface to, and knew the complete requirements, then you could do it
with static typing.  However, few projects I've ever worked on (and
none I didn't spec by myself for myself) have ever met these
requirements.
	       -- Darren

(Followups via email -- It'll expire before I have a chance to read
news again.)
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+