Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: The search for heterogeneous lists is still on!
Message-ID: <49730@nigel.ee.udel.edu>
Date: 4 Apr 91 00:51:52 GMT
References: <167:Mar3121:32:0891@kramden.acf.nyu.edu> <49605@nigel.ee.udel.edu> <11132:Apr319:34:0291@kramden.acf.nyu.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 75
Nntp-Posting-Host: nigel.ee.udel.edu

>I have never read the Pascal language definition. As far as I know,
>writeln can only take values of certain types, as defined beforehand by
>the implementation.

OK.  Given the definition of "union" as "a value from a subset of types
known at compilation-time of the callee", then writeln uses unions.

[I said something like "What is dynamic typing but unions and callbacks?"]
>So you agree that C++, which provides the union types and callback
>functions (a.k.a. objects) with a reasonable syntax, suffices for
				   ^^^^^^^^^^^^^^^^^ debatable :-)
>everything you can think of to do with heterogeneous lists? In other
>words, you agree that people don't use heterogeneous lists except in
>ways handled by a *statically* typed language?

No.  If I write a "List" class, I don't want to restrict the types
which can be put into a list.  By an earlier post, you said that a
hetrogeneous type is one which can contain "any expressible value", and
the logical conclusion is that a hetro list is one which can contain
multiple values, each of which is chosen from the set of any
expressible values.  Hence, by your definitions, C++ does not support
hetro lists at all, since all values in a list must belong to classes
which inherit from class ListEntry. And, as far as I can tell, this is
due to the fact that C++ is statically typed and not from some other
reason.

All languages with which I am sufficiently familar to determine that
they support hetrogeneous lists as you define them also support
dynamic typing; that is, the ability to declare a variable capable
of holding any expressible value. I suspect that this is the case for
all languages, because it would be necessary in a statically typed
language to have a "type" which is the "canonical hetrogeneous type"
which could be used to declare variables, function results, and so on.
In this case, it would seem to be a dynamically typed language, 
because you could just declare all your variables to be of that one
type and never worry about any of the static typing or type checking.

I think C++'s requirement that a value be declared to have a certain
type is an impediment to reusability, especially of collection
classes.  If I don't make a class a subclass of a list-entry class, I
can't put it in a list.  The act of making it a subclass of ListEntry
could break things in several ways, the least of which is not having
access to all needed sources to recompile, or needing to write
utilities to convert stored binary images of such classes to the new
format before reading/writing them.

As I previously described, whether or not an integer (say) can be a
member of any given list seems totally orthagonal to the operations
that should be available for an integer.  The concept that I need to
implement or even declare "find next element of current list" for
integers, automobiles, employees, etc, seems unacceptable to me once I
became experienced with languages where this is not needed. It would
be like having to declare, at the time one declared a structure,
the complete list of all functions which would return this structure.
For any given program, you eventually do this; the difference is
*where* you declare it, a purely syntactic distinction. 

I think a huge amount of things for which people use hetro lists today
*could* be done with static typing, explicit unions, explicit callback
functions, and sophisticated preprocessors. However, I don't see any
real benefit to this except marginal efficiency. Allowing the mix of
static and dynamic typing is the best, IMHO. However, I feel that in
such a mix, static typing should be treated as a special case of
dynamic typing rather than vica versa.  I.e., there shouldn't be any
place where a statically-typed variable is permitted that a dynamically
typed variable is not. Making dynamically typed variables the special
case, to be used only in special constructs, undermines their utility,
since every general utility you write would still have to deal with both
static and dynamic types. 
                                 -- Darren
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
  +=+=+ My time is very valuable, but unfortunately only to me +=+=+
+ When you drive screws with a hammer, screwdrivers are unrecognisable +