Re: ADT Lib (4.2)

[Tim Teulings <tim@edge.ping.de>]

Hallo!

> Remaining problems: 
> 
> Where to declare such extended riders?  Since a plain `Container's
> semantics do not support either of these extensions, I feel they need
> to be defined together with other abstract classes.  If all things
> fail, we can always throw them into Container.Mod, of course, either
> by declaring extensions of `Rider', or by putting everything into
> `Rider' (similar to the way Channel.Reader/Writer does it).

As mentioned in my other mail, I'm not sure if a container baseclass
should support iterators at all, in fact I'm not sure if a container
baseclass is suitable in general. However I but suggest to put
iterators into an own module named Iterator.Mod. The connection
btetween ADTS and Iterators is not that strong that they must be place
in the same module. Also, sinnce all classes are abstarct there is no
need to put them into the same module to access internal attributes and
methods.

> If the "positoning" capabilities of riders are implemented as
> specialized subclasses: How can this can be combined with other rider
> capabilities we might want to create?  If we have two orthoginal
> capabilities, Oberon-2's single inheritance will prevent us from
> implementing both as class specializations.

Correct. But about which additional class do you thing of? We agree
that we have to make a destinction between Writers and Readers. Perhaps
we should even think of different Writers? The SQL query language makes
a clear difference between INSERT and UPDATE so perhaps we should think
of Inserters, Updaters and Readers? This is of course not a proposal
but only somekind of creative , speculative thinking. Also I'm not
sure, if a Writer should be a superset of a Reader? Is this really
true? We already found out that navigation of Inserters is very
different on different ADTs.

> I believe you have been voted down on this.  For all practical
> purposes, the _most basic_ rider can only replace, and sometimes it
> can't even do that.  A rider (or writer, if you like) is not the
> preferred method to create new container elements.

However it is the only way to generical copy, move or sort elements. You
need Inserters and Updates with a clear semantic for a number of
algorithms. Note, I do not propose to put them into a container
baseclass but their should be special Iterator classes for that. ADTs
then can choose to support them or not.

> Ok, r.Skip(n) it is.

Skip is an advanced feature of an iterator and I'm not sure, if it shouldb
e a feature of the most general and most simple Iterator which I called
sequential iterator.

> This kind of distinction is exactly what I was hinting at in my
> previous posting (whithout knowing this myself, of course).  The
> `Modifier' will have additional methods, and will demand additional
> properties from the data type it is operating on.  [Let me repeat
> myself: I do not want to work out this part of the lib.]

As told a few lines above, I'm also of the opnion that Writers and
Readers are fundamentally diffferent. However I'm not sure, if a writer
is a superset of a reader. Perhaps an Writer has a far more limitted
interface?

> I'm not sure what you mean with `Iterator'.  Myself, I see both
> `Rider' and `Modifier' as something that is moved along by the user,
> while an `Iterator' is something that is applied to a list (container,
> whatever) as a whole, as an atomic action (from the callers point of
> view).  Therefore I will quote again the relevant part of List.Mod
> (they are list-centric, I know), and ask you to describe how your idea
> of `Iterator' differs from mine:

> PROCEDURE (l: List) Apply* (op: StdTypes.Operator);
> (* Successively applies operator `op' to the elements of `l'.  *)
>   END Apply;
> 
> PROCEDURE (l: List) Map* (fct: StdTypes.Function): List;
> (* Successively applies the function `fct' to the elements of `l', and collects
>    the results into a new list.  The list `l' is not destroyed.  *)
>   END Map;
> 
> PROCEDURE (l: List) Select* (pred: StdTypes.Predicate);
> (* Successively applies the predicate `fct' to the elements of `l'.  All nodes,
>    for which `pred' evaluates to TRUE, are collected into a new list.  The
>    original list `l' is not modified.  *)
>   END Select;

No, in my view Rider and Iterator are a synonym for the same thing.
There is no pricipal distinction as you are proposing it with the above
lines. In fact, in my opinion the above three methods are superfluous
if we will implement iteraotr correctly. Thinking of algorithms that
are applied on ADTs we would implement the above feature differently
and more generically (like C++ STL does):

Lets take Apply as an example. Applying data is an algorithm. An
algorithm can be implemented a normal procedure or as record method
(I'm not sure if we need to implement algorithms as classes. I
currently see no use for it).

The procedure Apply would have the following parameter:

A iterator (a simple sequential one would be enough) and the operator.
The Apply method simply would use the iterator to get acess to all
values and then would apply Operator an each value (note, that this is a
dangerous think, since it bears a hidden update action. What would
happen if we change a value that is a sort criterium?). Implementing
Apply as a simple procedure only working on iterators has the flowwing
advantage: We only need to describe the Apply algorithm once. We do not
need it to be implemented in every ADT. ADTs do not need to support an
apply algorithm (or any other algo) directly. In fact we will save a
lot of simple code. We can work generical on any ADT that at least
supports a sequential iterator.

An example for the Map shows another nice feature:

The Map algo would have the following parameter: A sequential iterator,
the function and an insert iterator. I do not describe here how the
Map procedure the function do interact to select the value that should
be inserted by the insert iterator, there are a number of possible
implementation which we can discuss later. However, besides the already
given advantages, we now see the power of a generic inserter. We can
read, filter, move, copy values is such a way that neither the type of
the source nor of the destination ADT must be nown to us.

I will try to answer all mails that arive here until 17:00 MEZ. If MvA
can posts his commentary a little bit earlier we can go into another
round before I must leave. I think the understanding of the priciple
iterator technic as used by the STL can give our project some major
kick or at least can influence a number of decisions.

-- 
Gru...
       Tim.