Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: CHALLENGE: heterogeneous collections
Message-ID: <3APR91.00595260@uc780.umd.edu>
Date: 3 Apr 91 00:59:52 GMT
References: <27MAR91.22130574@uc780.umd.edu> <49187@nigel.ee.udel.edu> <28MAR91.21053267@uc780.umd.edu> <49584@nigel.ee.udel.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 76

Darren New writes:
  [big long apology]            ((thanks, wasn't expecting that))
  [recap of discussion thread]  ((looks more-or-less correct))

>Anyway, so why would you not call a list inside of a window structure that
>tells the window what buttons, scrollers, and other subviews it contains,
>a hetrogeneous list rather than a list of pointers to tagged structures?
>I see little difference between this list and a list of "string of bits
>or characters" except for the size of the structures.
> 
>Are you saying that because the elements of the window list are not
>stored inline then the list is not hetrogeneous? Or is it because the
>type tags in the window example are stored with the elements of the
>list rather than actually in the list?  What about the case where the
>list, the types, and the bits are all physically stored disjointly?
>Or is it that in one case, you would mentally envision it in one way
>and in the other case you would mentally envision it the other way,
>regardless of implementation?

Hmm...  

(Why)  Because I can operate on the list without checking the types.
This occurs because I'm not writing the windowing code, you are :-)

I suppose, also, it is because none of the information is stored inline
is the reason I'd call the list homogenous.  That is, perhaps, an
arbitrary distinction.

I don't put a whole lot of emphasis on the type-tags which the
language uses to manage storage.  I have to be aware of them because
they have an impact on efficiency and speed, but...  hmm...

I look at "type" as meaning "x is in the domain of function f".  So I
might, for instance, consider even numbers to be a type, or maybe sets
composed of unique elements from the ranges 1 .. 7, 1000...9999,
and/or 100000...100999.

Now if I had three functions, one of which took as arguments numbers
in the range 1..7, another 1000...9999, etc., then maybe I'd
consider those sequences of numbers to be hetrogenous lists.  The
point being that I had to write three separate functions to handle
them, and I have the overhead of a conditional in front of each
function application.  Maybe that's an artificial distinction.

If I wanted to make sure that these numbers weren't accidentally
treated as arithmetic objects, I'd have to encapsulate them anyways
(put them in structures and work with pointers to these structures).
So you could say I'm being backwards...

It boils down to:  I like to think of "pointers" as a single type.  It
is only when I examine the data that they are pointing to that I like
to think of the data as being typed.

This is influenced by the primitives I normally work with.

>>I hope my statements are now understandable.
>>Raul Rockwell
> 
>Hmmm...  Tell the truth, it didn't really clarify much, unless you mean
>that a list of two different types of structures will always be
>homogenous because you always store "pointers to tagged structures" but
>an intermixed list of bits and characters is hetro because they are
>physically stored ajacent to each other.

Ahh...  It is not that I consider the structures to have the same
type.  It is that I consider the pointers to have the same type.  All
of my primitives that work on pointers (except the ones that extract
information from the encapsulated structure) will work on any list of
pointers.  This is just an off-the-cuff sort of classification, I
admit.  

If there is anything left to say on this topic, it is probably on the
distinction between what a function can meaningfully operate on vs.
what information can be meaningfully stored.

Raul Rockwell