Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!yale!cmcl2!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Generecity and static/dynamic typing
Message-ID: <794@optima.cs.arizona.edu>
Date: 18 Mar 91 23:44:22 GMT
Sender: news@cs.arizona.edu
Lines: 98

In article  <2840@enea.se> Erland Sommarskog writes:
]
]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.

True.  But there are many cases where you don't.  In particular you
don't have to write typecase code for functions that just pass data
around without doing type-specific operations.  This includes such
things as insert and delete functions which are quite common.

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

Not true.  In fact this is the exception rather than the rule.

]2) Comparison is not defined for the two objects, type error leading
]   a crash, which may or may not be acceptable...

First, the programmer who was responsible for testing the sort
function gets fired for gross negligence (the most minimal testing
should have caught this).  Then if error stops are unacceptable the
programmer who was responsible for execption handling may get fired
for gross negligence also, depending on the circumstances.

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

Most likely it is correct.  If you are sorting two objects with a
generic comparison then the actual ordering better not be important.
If the comparison is not logically correct, then you may have a third
programmer to fire.  Be a little more careful in your hiring practices
in the future.

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

Yes, but in Icon you didn't have to implement the list.  And if you
_could_ use the generic comparison, then you wouldn't have to write
the sort either, you could just say new_list := sort(old_list).  Or
you could use a dynamically typed language (like lisp) that lets you
specify in-place sorts and specify the comparison function.

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

OK, that helps you find the declaration.  Now you change the
declaration and you have to make pervasive changes throughout the
program.

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

This is bogus.  When you change a function definition in _any_
language, you generally have to make sure all of its previous uses are
still correct.

And my complaint was not that it is too much work to find a single
declaration.  The problem with having to keep all your declarations
consistent is that (1) you sometimes forget to do it, wasting a
compile-debug cycle, (2) when you change a declaration you have to
make pervasive changes throughout a program, which is not only time
consuming itself but also (3) it tends to provoke further errors.  All
this combined with the observation that (4) it isn't necessary.

Obviously (1) through (3) may be applied to the situation of changing
a function definition, but in that case it _is_ necessary to update
all uses of the function, so why complain about it?  Actually,
although you can't elminate this problem you can reduce it either by
using a hierarchical type system or by dynamic typing (or a
combination).
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman