Re: ADT Lib (4)

[Michael Griebling <mgriebling@inspired.to>]

Michael van Acken wrote:

> First some general stuff:
>
> MG> I'm interested in an ADT library -- I'm just going to let you guys
> MG> work out the details.  Ever hear the expression: "Too many cooks spoil
> MG> the broth".  I'll be happy with whatever you all come up with.  If
> MG> anything comes up that I have a strong opinion about, I'll definitely
> MG> let you known.
>
> Thank you for your vote of confidence.  Your confidence may be
> misplaced, though, for three reasons:
>
> First: In the current discussion my postings draw from my own
> experience (of course), but I have no experience whatsoever with class
> libraries like Smalltalk, C++ STL, or Java API.  I need to draw onto
> other people's experience to create a solid base for the library.

The only experience I might be able to contribute was from some Adalibraries which
I worked on and have seen.  So far, it seems, your main
problem is that no one seems to have looked at the existing Ada libraries
and just shamelessly cloning them.  There are a lot of ADTs in Ada out
there for the getting.

> Second: The direction of the basic design of the ADT lib primarily
> follows my own priorities.  If you have other priorities, you need to
> push them on the mailing list.  If you want to have them implemented,
> you need to convince me that the idea is good, and then you need to
> provide help with integrating it into the library outline.
>

I'll let you know when our priorities differ.  So far, I've seen
nothingparticularly bad.  A lot of good discussion has happened.

> Third: I am trying to coordinate the design of an ADT lib, I am _not_
> writing one.  I will not implement the stuff.  Others will have to
> provide the Oberon-2 code to fill the modules once the general outline

No problem.  I don't mind doing a couple of modules, as long as everyone
else does a couple as well.  You're excepted, Michael.  Generally, the
hard work is doing the design of the interface and the concepts to give a
solid class foundation.  Coding is trivial.

A couple of suggestions for the class libraries:

1) A "Set" module which represents the mathematical concept of a set
    with an arbitrary number of unique elements.  Something like this is useful in
    compiler register allocation algorithms and other places.  Every
    Ada ADT has one of these.  Sets contain unique elements of
    something.  In Oberon-2 we're probably limited to integers although
    Ada allows enumerated types.

2) A "Bag" module represents a collection of entities which could be
    repeating.  As a real-life example, a bag of marbles would be a close
    match to how the software implementation would work.  Bags are
    useful in statiscal applications where one is counting the occurrences
   of some event or maybe in an execution profiler.

As well, there appears to be some confusion over the levels of abstraction
which should be used in an ADT module.  The examples I've seen in Ada have
been fairly high-level concepts which could be mapped to several different
software implementations.  For example, a Queue is an abstract concept.
Typically, implementations will define modules such as BoundedQueue
and UnboundedQueue.  The bounded queue will typically be statically
based while the unbounded queue will be dynamically resizeable.  A List
would also be an abstract concept.  You would then have BoundedList
and UnboundedList modules.  It is entirely irrelevant whether the list is
doubly-linked or singly-linked or implemented in an array.  Of course, the
BoundedList is most likely an array implementation.  Operations on Lists
would be to Remove, Insert, Iterate.  The iterator would be passed a
procedure parameter which is applied to each element in the List.  This
isn't intended to be an exhaustive list but just to give an idea of what is
being done with Ada.

> has been established.  I fear, that people are not willing to devote
> time to implement parts of the library they consider not useful, or
> whose design they consider to be flawed.  In this case, we may end up
> with a library outline that will never turn into a library, which
> would turn this whole discussion into an exercise of futility.
>

I think with the architecture I've described it is possible to define
librarymodules which should satisfy everyone.  The key thing will be to define
useful classifications and abstract concepts which are worthy of
implementation.

Just my two cents worth.

Michael G.