Re: ASCL a doomed idea?

["Mark Lundquist" <mlundquist2@attbi.com>]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3C153926.102B17B1@boeing.com...
>
> > > An iterator procedure is the only thing that is an iterator; anything
> > > else called an iterator is misnamed.
> >

I have a tool in my garden shed.  It's basically a trencher, but with a
double head -- you reverse it and it's like a three-tined hoe.  This tool is
called a "cultivator" -- that's what the hardware store calls it, anyway (I
used to call it a "hoedag", and still do, just to irritate my wife :-).

Anyhow... the thing is, Jeff, even after many hours of watching it from my
lawn chair, this thing will not actually *cultivate*.  It just sits there,
propped up against whatever I have propped it up against.

I suppose I should take it back to the hardware store for a refund...?

Alexader Stepanov came up with this idea for how to write a suite of
collection classes, where the collection operations were *not* primitives of
the collections.  That way, the implementations of the collection operations
can be reused, i.e. shared across many collection types, instead of having
to be written custom-like for each one, and it allows the functionality of
the collection classes to be extended without the limitations of using
inheritance for the extension.  The collections he calls "containers" and
the operations he calls "algorithms".  The coupling mechanism between the
two is an abstraction he calls an "iterator".  Now, this idea is embodied in
the Standard Template Library for a language called "C++", which many, many
programmers in this quadrant know (or at least are able to claim to know
enough to get hired).  As a result, most sentient beings in the galaxy are
familiar with the concept of an "iterator" as the coupler between containers
and algorithms.

I'm not saying that the term "iterator" at all follows from Stepanov's usage
of it.  And I'm not saying he was the first to use the term "iterator" to
refer to a handle for traversing a collection.  What I am saying is that
since he was the one who consolidated and promulgated the concept of
"generic programming", he kind of gets to choose the terminology, for better
or worse, just because it's a powerful concept and so whatever nomenclature
he picked was bound to stick.  If he had called them "enumerators" instead,
everyone would have accepted that and we'd be stuck with "enumerators"
instead.  If "iterators" gave anyone heartburn, it wasn't enough to get the
name changed.

I feel very strongly that a collection library for Ada must have a "generic
programming" architecture, i.e. algorithms abstracted away from the
collections.  If that is to be the case, I think we should stay with the
universally understood and accepted nomenclature.  Here we are, trying to
bring Ada out of the stone age as regards having a decent standard library,
and the last thing I want to have to do is explain to the rest of the world,
"Well, this here is what is commonly called an 'iterator', but we call ours
a Dookus because strictly speaking, it does not iterate, being as it's just
an object and cannot actually do anything on its own."

I don't think you're gonna be able to get many people to go along with you
on this one.  You're rowing against the tide, and you're gonna end up being
the only one in your boat :-).

And I can't say much for your choice of name for the itera... I mean, the
uh... the dookus.  "Position" is what you call it, right?  Well, the term
"position" connotes like an index or something -- you know, "first",
"third", "last" or whatever, right?  "Position" does not carry the meaning
of something that denotes an element.  Like with an index, the value '7'
doesn't denote an object -- you have to combine the index with a container
(an array) to get a name for an object:

        An_Array (7);

It's like a house number as opposed to a full street address.

A Dookus is not like an index.  A Dookus is an abstract pointer.  A Dookus
really does denote an object, and to get the object you do not need to know
what collection it came from.  You don't need the collection, you only need
the Dookus.  We provide some operation like "Value" or whatever, for
"dereferencing" the Dookus.

Suppose you have a Dookus denoting an element that happens to be the first
element in a linked list.  Then suppose you insert a new element at the
"first" position of the list.  Your Dookus still denotes the same element,
even though its notional "position" has changed -- it is no longer the first
element in the the collection, it is now the second.  It seems really
strange to say that it still has the same Position!

Best wishes,
Mark