Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: CHALLENGE: heterogeneous collections
Message-ID: <49187@nigel.ee.udel.edu>
Date: 28 Mar 91 20:10:52 GMT
References: <26MAR91.19392004@uc780.umd.edu> <49078@nigel.ee.udel.edu> <27MAR91.22130574@uc780.umd.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 86
Nntp-Posting-Host: snow-white.ee.udel.edu

In article <27MAR91.22130574@uc780.umd.edu> cs450a03@uc780.umd.edu writes:

>Did I say that?  hmm...
>If I have a bitmap, that's a homogenous collection, and I sure don't
>carry type information along with each bit.

Well, comparing it to the example of buttons and subviews and
scrollbars in a list, yes you said that.  Of course, there will be
homogenous lists where you don't carry the types along. But that isn't
what we were talking about.  We were talking about seemingly-hetro lists
which you said were actually homogeneous.

>On the other hand, if for some reason I wanted a collection of bitmaps
>and strings, I'd have a list of pointers to data descriptors.  One
>pointer (and descriptor) for each element of the list.  Those data
>descriptors would carry "type" [and size], etc.  But I deal with a
>homogenous collection: a list of pointers.

And I deal with a hetrogeneous list of both strings and bitmaps.  I
look at how I use the data, and you look at how you implement
hetrogeneous collections.  I don't want to deal with pointers to
descriptors; I want to deal with bitmaps and strings.  How that gets
implemented is secondary to the problem that needs strings and bitmaps
to solve.  Similarly, I want to deal with symbolic names for functions
and variables and let the linker deal with resolving it instead of
working with stack-frame offsets; where a variable is in the stack is
not part of the solution to my problem. When I have a floating point
number, I don't want to deal with a 3tuple of <sign, exponent,
mantissa> and recode all the floating point operations in terms of
this. I want to deal with a float directly. Of course, assembly
language (or hardware) will have to deal with it as a 3tuple, but
I don't want to. The closer a language can come to providing the data
types required by my problem, the easier it will be to solve that
problem.

If the language lets me deal with hetrogeneous collections directly by
allowing the type of a variable to change dynamically over time, then I
have an easier time dealing with bitmaps and strings.  If I have to
implement bitmaps and strings as pointers to data descriptors carrying
a type tag and then within my routines check the type tag, I have more
work to do without any more solved problems. I also don't want to have
to tell bitmaps and strings that they may both be put in a list
together. The fact that a bitmap might appear in the same list as a
string is completely irrelevant to the functionality of a bitmap.
Requiring me to do so would be like requiring me to list all of the
variables that may hold a bitmap *in*the*description*of*bitmaps*
instead of in the descriptions of the variables; clearly, this reduces
reusability.

>Personally, if I have bitmaps and strings, I'd prefer to refer to them
>by separate names (that is, store them in separate variables).  And as
>a general rule, this runs faster (than using indirection).

I too.  However, sometimes (like with a window containing a graphic
view and a textual view and buttons and sliders and ...) you need to
put things of different types that behave similarly in some way,
together.  I sometimes need to store them in a hetrogeneous
collection. Just like sometimes I store both source and executables
in the same directory. I don't want to have to tell 'ls' in advance
what the possible types of files are in each directory.

I don't deny that static typing is useful; I don't think anybody here has.
I don't deny that dynamic typing can be implemented on top of static
typing and typecasts/unions; objective-C does exactly this.  I don't
deny that hetrogeneous lists can be implemented by homogeneous lists of
pointers to tagged data; I don't know of any dynamically-typed
languages where this isn't how it's done.

I deny that dynamic typing is useless: all dynamically-typed languages
I've seen come with a large reusable class languages. 

I deny that hetrogeneous collections are never needed; I've provided
many lists of hetrogeneous collections that people use every day.

I deny that the best way to think about dynamic typing is by worrying
about how one could implement it in C.

>Raul Rockwell

             -- 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 +