Re: Generic Package

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Markus E Leypold"
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
> message news:ijwszq2tiq.fsf@hod.lan.m-e-leypold.de...
> ...
>> > I actually agree with DK, using his definitions. The problem is that no
> such
>> > set could ever be constructed (even on a piece of paper, the elements
> have
>> > an order). So the fact is completely irrelevant: there is no such thing
> as
>> > an unordered set.
>>
>> I repeat: There is a bit of confusion on 3 different things:
>>
>>  (a) the way we write down sets (notation)
>>  (b) orders (binary relations with certain properties)
>>  (c) orderable sets, i.e. sets for which an order can be defined.
>
> Probably. But I was *very* clear, I was using DK's definitions. Whether they
> match some mathematical definition I don't know. You're arguing from some
> abstract mathematical definition and assuming everyone agrees with it. 

No really. Calling something an ordered set because one can write down
the elements in some order "doesn't wash" IMO.

> That doesn't wash. (Your definition is consistent, and fine, its
> just different than the one I was using. Thus it is hard to not talk
> past each other.)

Quite. Actually I proposed 2 definitions, one mathematical, the other,
very similar, like what "usually" is used as an ordered container in
programming (or in textbooks about abstract data types). I put
"usually" in '"' because I see that people probably have different
experiences. Every other definition (especially those that don't start
with "A ... is a thingy with ..." I still see with distrust.

> ...
> ...
>> > Of course you can if you assume primitives that effectively give you an
>> > order.
>>
>> No. Have you read the functional spec I wrote? I just use set
>> operations and a suitable cursor abstraction. Of course the choice of
>> the next element is not deterministic in the specification but that is
>> as it should be: It indicates that the implementation has a certain
>> degree of freedom here.

> I didn't recall it, but I think it actually proves my point. You've just
> moved the magic into a "cursor" abstraction and a "Next" abstraction - which
> shows far more implementation than the "foreach" iterator abstraction I was
> thinking of. 

One can define a foreach operator which applies a given operation to
each element in quite a similar way. I did it with a cursor, because
(a) that would be the way iteration would be implemented in an
imperative language and (b) the discussion started out with
iteration. My cursor abstraction doesn't show much implementation
(actually it cannot be implemented very efficiently in this form
because it has to "freeze" the set state state into the cursor when it
is created with first) -- what I wrote just describes what a cursor
does, specifically, selecting the "next element", without recurring to
some kind of order defined on the set or some kind of internal
adresses. And that is the point I wanted to make: a specific order of
the elements might emerge during iteration, but one doesn't need an
order to define (the contract of) an iteration on a set without any
structure (addresses, order) otherwise.

> (There's no good reason for a set to have a cursor abstraction,
> after all.) 

There is a good reason: if you want to iterate over the elements in a
loop, the cursor takes the role of the loop variable, i.e. catches the
state of the iteration (or call that iterator if you like). Foreach
(as I understand you) would be more like a composition operator or a
second order function: It would take a operation and a set and create
an operation from them which is effectively the application of the
operation to every element of the set. Since there are no second order
functions in Ada, that would have to be implemented with a generic
function and using a downward closure or some trick like this.

Whatever -- therefore my preference to express the same thing with an
iterator/cursor. It seemed more natural for a procedural language like
Ada.

> And "Next" gives you an order, even if that order is undefined.

I get an undefined order? :-/ So I'll give you some money, even if it
is not existent. :-)

I think we would have to discuss about the meaning of order, to get to
the ground of this, but better not here :-) and better not now: After
all I never had problems with iterating over sets before, so why
should I suddenly acquire the need to discuss them -- and I gather you
have better things to do, too.

> ...
>> > And I would hope that I was done reading this bulls***, but I'm sure I'm
>> > not...
>>
>> Sorry. I'll stop. No sense in annoying people. But I'm a bit pained
>> that you characterize my "contribution" as BS, whereas you tolerate
>> DKs prevarications pretty well. Never mind.
>
> Sorry, my comment was uncalled for. And it wasn't really directed at you but
> more at everyone who's kept this thread going for what seems like months.
> (And I'm guilty of that, too. I probably ought to get a newsreader with
> thread kill...)

I've now given, what I hope is the last contribution coming from me in
this thread, only because I think that this is one of the rare
opportunities to make my point understood and because I argue it is
related to c.l.a. (i.e. I'm talking about specfying an abstract data
structure formally).

I admit, I'm guilty, too: My conflict is with DK, not with you -- and
there is no sense in leading a proxy war.

Thanks for the opportunity to get my arguments straight once before I
stop and a good day to you :-).

Regards -- Markus