Re: GCC 4.0 Ada.Containers Cursor danger.

["MMM" <terekhov@emc.com>]

Georg Bauhaus wrote:
> MMM wrote:
>
>> The reason is that, if one
>> remember some mathematics, having an order is a fundamental property
>> that distinguish vectors and lists on the one side and sets and hashes
>> on the other.
>
>
> I think it is not too helpful to consider Ada.Containers to be
> derived from some collection of mathematical notions and from
> nothing else.
>
You are right that for the person not familiar with mathematics
that will be of no help. But I suspect that people designing
computer programs in general and designing programs in Ada in
particular have some knowledge of at least simple math. Note also
that mathematics is the lingua franca not only for the science but
also for programming and computers in general. Note also that it is
not "some collection of mathematical notions", it is a well known
theory, while current proposal of container types *is* some collection
of mixed notations and it looks like it is derived from "nothing else"
only.

> First, Ada.Containers is not trying to approximate some notions
> from linear algebra ("orthogonal normal basis"), metaphorically
Note that this notion is not limited to linear algebra and I'm not
agitating
for implementation of this notion in Ada.Containers in any way!
;):);):)
What I've ment is that library should implement all commonly used and
accepted abstractions and then, if it is practical, implement all
needed
specialisations, mixtures, etc.

> or not. ;-) You'll have justify the implication that
> we should build computer libraries around some specific
> choice of notions loosly derived from mathematics. Doing this
> is not a matter of course, as reactive systems are not all
> about mathematics.
I'm not sure what you mean by "reactive systems", but anyway.
My justification is very simple. Such a generic library as
Ada.Containers, which should serve as a basis for a wide variety
of programs, should be based on a well known abstraction commonly
accepted and understood by every programmer, not only by couple of
authors. The foundations of this library should be derived from the
common experience, not from the experience of one man. For example
of what other programmers think about containers see the following
links (as well as how this abstraction is implemented in other
languages such as Java, Python etc.)

http://en.wikipedia.org/wiki/Set_%28computer_science%29
http://en.wikipedia.org/wiki/Hash_table
http://en.wikipedia.org/wiki/List_%28computer_science%29
http://en.wikipedia.org/wiki/Array

Actually current proposal have to justify the use of such a
wonderful abstractions as Ordered_Sets, Hashed_Sets, Hashed_Maps and
Ordered_Maps as a basic set of abstractions.

>
> Second, the way Ada.Containers invites you to think about the order
> of elements ("containers are nothing, elements are everything").
> There might be some physical/logical correspondence between the
> order of elements in some container on the one hand, and their
> order as implied by the user's ordering functions passed during
> instantiation. Or there might not. It is more important what a
Can't argue with that ;)

> user wishes to to using the elements that happen to be elements
> of some collection. I.e. while it remains advisable to choose the
> proper container, Cursors are among the means to choose different
> containers when the need arises, ideally without disturbing the rest of
> the program.
I can't say I understand you here, but anyway, how cursors could
help to change container type without disturbing the rest of the
program?

>
> There are a number of "orders" of elements in this discussion.
I think you overestimate a little here. Order either is present
or is not.

> There are those on which you seem to build your correspondence, IIUC.
> Elements ordered relative to one another in the list and vector
> abstractions,
> because that is what a mathematician might assign to the notions.
Yes, YUIC. But it is not because "a mathematician" created this notion.
This is how all mathematicians *and* programmers understand it.

> But some elements are ordered relative to one another in ordered sets or
> maps
> that are ordered by key. This order need not entail the use of a list,
> and indeed requiring List/Vector <-> order will defeat several uses
> of the library which is rather more flexible. If I want a set for
> (a) memebership test, and (b) an ordered collection, then why should I
> store
> the elements in some List oder Vector just because I want element
> insertion to preserve order as well?
This exaple doesn't count. Membership test is common to any collection.
If you only need ordering then you can use array/vector or list
depending
on what kind of access you need. Why would you choose a set or hash?
And if you chose to have such a specialized type as Ordered_Map then
you

> Indeed, a close correspondence of order and choice of container
> will defeat some generic algorithms.
Care to provide an example of such a generic algorithm? If your
algorithm is so generic that order and access details are not
important, then express you algorithm in terms of Abstract_Collection.
Then averyone could choose any collection type that fits the task
in question most.

>
> I think it is of no primary concern here that some branches of
> mathematics can
> do without ordered sets, and that there is a natural ordering by position
> in a list. The library is for programmers, not for mathematical
> housekeepers. ;-)  There is a treasure trove of mathematical theory of
> computation that starts from computation in computers, and not the other
> way round :-)
>
I really hope that the smiles you put here really mean something ;)
Otherwise your disregard of mathematics and computer science could led
you to reinvent a lot of weels. ;( One need to have a knowledge to
distinguish a therasure from trash :) The sad thing is that this
proposal
forces the whole Ada comunity to learn the hard way and to reinvent
collections from scratch. Take a look at others languages collections
implementations.

>
>
>> Another silliness is overgeneralization of the
>> 'iterrator' concept and renaming it to 'cursor'.
>
>
> Given the operations of Cursors, I can see clearly how I can
> use Cursor operations in iteration. OTOH, iteration
Of course you can! One can use his computer to watch TV or even to
move his lawn, but that is not a justification for renaming this
computer to TV-set or mover. Authors of this proposal stated that
they model their library on STL. So why to name the same thing
differently?

> means doing something again, but an STL iterator (a pointer,
> really, or cursor if you wish) doesn't require that I do something
> again...
So what?

>
>
>> The problem here is that this terminology doesn't reflect the
>> fundamental differences between these types and mixes underlying
>> mathematical conncepts in some unregular way.
>
>
> If the library confuses a mathematician because he/she is used
> to some meanings of words, then maybe emphasising the Ada definitions,
> which relate to computers, will help?
>
Ok, it looks like you really hate mathematicians :) Why? To soothe you
I
can tell that I'm not a mathematician. I'm a physisist by education
and a programmer for the last 20 years. This library confuses me as a
programmer. I've always loved Ada 83 and 95. I really believe that its
standard library stands out by its clarity, completeness and
correctness.
Current proposal for Ada.Containers doesn't meet these high standards
yet.
It is too raw. It looks like the authors of this proposal didn't have a
goal of creating clear and solid foundation for future library
development.
It looks like they provided just a bunch of special case algorithms and

abstractions using far from perfect terminology. To understand this one
need
no degree in mathematics, just look around - STL,Java,Python, etc.,etc.

> 
> -- Georg

Mikhail