Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Generecity and static/dynamic typing
Message-ID: <2840@enea.se>
Date: 17 Mar 91 23:03:11 GMT
References: <595@optima.cs.arizona.edu>
Organization: Enea Data AB, Sweden
Lines: 83

David Gudeman claimed that you couldn't write a generic list handler
in a staticly typed language, which he claimed would force you to 
write code for any type that was expected. I objected this and 
described how genericity works in Ada and Eiffel.

>You aren't getting the same functionality that dynamic typing gives.
>To get that functionality you would have to declare a tagged union of
>every type in the program, and for each list function that deals with
>list values you have to do the right thing with the member of the list
>depending on it's actual type.  To compare two values you have to
>write code to check the type and do the right thing based on the type.
>You have to (in general) write seperate code for every type that is
>used in the program.

OK, I cannot write a polymorphic list handler in Ada or Eiffel
easily without a lot of extra code. On the other hand, in the
general case you have to do that for a dynamicly typed language
as well.

Or? Well, say we have this polymorphic list handler which you 
wrote some day some years ago. Now, after some years of maintenance
and modification we now get to the sitaution that we sort the
the list. Next to each other happens to be an account statement
and a security ("security" = item to trade with on the stock exchange),
so you compare them. What happens?

1) Question is moot. You can't define your types in a dynamicly
   typed language, you can only use the builtins. I have to
   admit that such a language does not seem very expressive to
   me.

2) Comparison is not defined for the two objects, type error leading
   a crash, which may or may not be acceptable depending the
   reliability and accessability requirements.

3) Comparison is not defined for the two objects, but the language
   implicitly uses the comparison operations for the underlying 
   types which are built-in to the language. This may or may not 
   be logically correct.

4) Both account statements and securities are built-in types in
   your language, so what's the deal?

5) You have written operations that compares an account statement
   and a security to each other.

Depending on the situation, 5 does not at all seem unlikely to
me. If you really need a polymorphic list handler, and you need
to compare the types from a non-general rule, you have to write a
lot of code, may it be Icon or Eiffel. If you are using some more
general rule, Ada is still out, but I wouldn't be too sure about
Eiffel.

Now in another article Gudeman says:
>It isn't that completely polymorphic lists are so useful, in fact
>they are rarely used.  What is important is the ability to change the
>types that can go in the list without making pervasive changes to the
>program -- and without having to look for a declaration for the list.

What a problem! If you are on VMS and have LSE/SCA on your system,
just say GOTO DECLARATION and you're there. I assume Unix or
GNU-Emacs something similar.

And may I add, you rarely change the list declaration, possibly
you modify the type that's in the list, add another field for
instance. But you have to do that in a dynamicly typed language
too, I guess.

But if finding the declaration is too much for Gudeman, he isn't
always that lazy. Look here, in yet another article:
>Whenever you change the way a fuction
>behaves, you (in general) have to check all the places it is used to
>make sure the change is OK.  All static type checking provides is a
>compile-time warning if (1) you have missed any uses _and_ and (2) the

First a correction: the compiler gives you a compile-time *error*.

Here he isn't afraid of jumping around the code to find every
single occurance. Sure he needs SCA or similar to do that, but
it is definitely not consistent with his reluctance searching
for one single declaration.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se