Re: List Container Strawman 1.4

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:koOS7.73$XC5.37@www.newsranger.com...

> >I've fixed that. For unbounded lists, the user can have up to 255 cursors
> >(iterators), dynamically allocated, which can be dynamically varied. The
> >limit of 255 is arbitrary, and could be increased if you think it
necessary.
>
> I don't think that really addresses the concern, which is that this isn't
really
> an "unbounded" approach.

Ted, what are you getting at, really? I don't give a flying Dan Quail
whether it is or isn't, in some higher Zen way, an unbounded approach. Isn't
the point simply that the user can have as many cursors (iterators) as she
requires?

> Not that I'm a huge fan of the approach the current
> strawman uses either. If you've been reading a while, you know I'd lean
towards
> making the users responsible for iterator safety. But the current approach
is
> the only one that we have been able to get general agreement on.

Frankly, I'm more interested in getting your agreement than anyone else's
(at this point). Are you saying you personally favour my approach? Since it
looks like we two are going to be producing this facility, who else has a
more important opinion? If other people don't like it, it's up to them to
make a noise.

> If you could
> convince folks that your (hugely) bounded approach was the way to go, I'd
> certianly put that in instead. But so far I see absolutely no sign of that
> happening. Not a single other person has come out in support of it in two
weeks,
> and I see no evidence that this situation would change if we were to delay
> things another two weeks.

On the other hand, why don't we do it my way, and see how many people
complain? I don't think anyone actually would.

> >The fact that an array version is included for each operation that has a
> >secondary data parameter is not just nice, it is necessary for the sake
of
> >efficiency. Consider the extra work done by converting the array to a
list,
> >and then applying that list.
>
> That's only an issue if you don't have the Strawman's "Splice" routine.

I don't think so. I can see it helps for insertion, but not for replacement.
Besides which, you seem to be advocating making a user do this:

   declare
      Temp: x.List := To(("Alice","Jenny","Frida"));
      It: Iterator := Side(Invitees,Back);
   begin
      Splice(Temp,It);
   end;

when my package would permit:

   Append(Invitees,("Alice","Jenny","Frida"));

You've got to admit, the latter is a bit easier, huh?

> >[1] I would prefer the name 'Element_Type' to 'Element' for the generic
> >parameter, since 'Element_Type' is what Ada.Sequential_IO and
Ada.Direct_IO
> >use.
>
> My opinion on the stupidity of "_Type" is probably well known by now. If
we were
> trying to emulate either of those packages in other ways, or there was a
good
> case for it possibly causing confusion, then it might be worth using
"_Type"
> regardless. But I don't believe either is the case here.

I agree it's stupid, but if we start trying to correct all the stupid things
in Ada, we might just as well start inventing a new language. I really think
most users are not going to say "Oh goody, how great that they changed all
the naming conventions to something better!". I think most would say "Oh
******* ****, they've changed all the ******* naming conventions to
something different to the rest of Ada!" Specifically, if the name 'Element'
is used for the data type (instead of 'Element_Type') that means the
function which retrieves an element cannot be named 'Element', which is the
name of the analogous function in Ada.Strings.*ounded.

> >[2] I would prefer a name other than 'List' for the list type, since
'List'
> >seems to be such a natural name for parameters and objects of a list type
>
> That issue (type vs. object naming guidelines) has been thouroughly
discussed
> already a week and a half ago. General names like "List" are for types,
while
> objects (and parameters) should be named something more specific that
designates
> either exactly what the object is, or what its role in the system is (eg:
> "Target"). This isn't just some rule I made up. The Ada Quality and Style
guide
> phrases it this way:
>
> * Use singular, general nouns as subtype identifiers. (3.2.2 - Subtype
Names)
> * Choose identifiers that describe the object's value during execution.
(3.2.3 -
> Object Names)
>
> You seem to worry that this will cause problems, but we already have a
package
> spec and it hasn't caused problems that I can see. I'm thinking we can get
by
> just fine in the body too. Those are the only places it should be an
issue, as
> everywhere else dot notation can be used to disambiguate.

Nicely argued, and I concede. Type names such as 'List', 'Set', and 'Contar'
(or 'Lookup'?) are reasonably appropriate in a generic package, since they
will indeed tend to be either qualified or renamed (by a subtype
declaration).

> >[4] If you consider their usage, the functions 'To' and 'From' are surely
> >confusingly named. What is wrong with 'To_List' and 'To_Array' (or
similar)?
>
> That may be a bit of an issue. I general I think things should be named
relative
> to the package name. If one uses full dot notation, things look great this
way.
> However, in this case it might be a bit obscure without it:
>
> Foo_List := To (Foo_Items);
>
> and
>
> Foo_Items := From (Foo_List)
>
> The flip answer to this it to use the package names anyway if it doesn't
look
> clear without them. However, it would perhaps be nice if things aren't
quite so
> obtuse without them.

   Foo_List  := To_List  (Foo_Items);
   Foo_Items := To_Array (Foo_List);

This seems a lot better to me.

   Foo_List  := Foo_Lists.To_List  (Foo_Items);
   Foo_Items := Foo_Lists.To_Array (Foo_List);

And this is perfectly okay, isn't it?

> >[5] Analogous to the Ada.Strings.Maps.To_Set function, the function
> >'Singleton' should be named more like 'To_List' with a parameter named
> >'Singleton'.
>
> I could see it as an overload of the "To" function, or whatever we end up
naming
> it. But its not that big of a deal either way.

So is that a "yes" then? ;-)

> >[6] I think it would probably (but not necessarily) be better to have the
> >list exceptions gathered into the x.Lists parent package, so that there
is
> >only one of each exception (rather than one for each instantiation of
> >x.Lists.[Unb|B]ounded).
>
> That's most likely true. When we have more than one package we can do
that.

No time like the present. Let's do it now.

> >[7] As mentioned, I actually want to remove directional parameters.
Instead,
> >all that is required is a 'smart reverse' operation. This merely switches
an
> >'effective forwardness' flip-flop between actually forward and actually
> >backward. All the operations must be programmed to behave according to
the
> >effective forwardness (not difficult).
>
> I'd like to see this,

All that is required is that the pair of pointers in each node, cursor, and
the base, are made into a duple (array):

   type Direction is (Forward, Backward);
   type Ref_Pair is array (Direction) of Node_Ref;

Then the base has a component that indicates the current 'sense' of the
list:

   EF: Direction; -- Effective Forward

All operations then simply refer to L.Ref(L.EF) to get the 'current forward'
node pointer, and L.Ref(Opposite(L.EF)) to get the 'current backward' one.
(of course, one might have two components, EF and EB.) To apparently reverse
the list, all you do is reverse (set to its opposite) EF (and EB).

> but I should note that the less state-full calls are, the
> easier they will be to parralelize.

Fair point in general, but I think you will find that it is very rare, in
practice, for a list to be operated on in parallel (conversely, a slightly
different idiom, the queue, is used almost exclusively in parallel). By
contrast, sets and contars (and others) are often used in parallel. It's one
of those little oddities.

> I also get worried whenever I hear anyone
> use the word "smart" in the context of a computer program. :-)

You're quite right there, of course! It's only one short step away from
artificial intelligence, and we all know where that leads to. :-)

> (several other parameter naming issues removed)
> I'll look into the merits of all these. I don't think we should let
parameter
> names hold up the works at this point though. We'll never get everyone to
agree
> that they are all perfect.

As I say, never mind anyone else. Let's agree between ourselves, and let's
do it now (it's easier that way).

> >[13] I have a problem with passive iterators. Texts say that they should
be
> >provided in addition to active iterators, but I rather feel this is like
>
> Frankly I totally agree with you here. I don't like to use them either.
But
> several people here do, and were quite insistent that they need to be in
there.
> Since it doesn't seriously hurt anything to put one in (its not like it
has
> cascading effects throughout the whole package), I can't really see
keeping them
> out just because the two of us don't like to use them.

Reluctuantly accepted.

> >[14] I feel that the term 'iterator' should be reserved for a construct
that
> >is applicable to all container types (and which is therefore
monodirectional
>
> Since we don't and won't have such a thing, I don't see the sense in
reserving
> the term for that.

This is extremely important, to me. Could you explain why you don't want
container-wide iterators? It seems like a bizarre attitude, to be frank.
Remember, the STL iterators are all container-wide, and I believe this was a
fundamental design decision.

> >[15] The reason why I made cursors internal to list objects (rather than
> >providing a separate cursor type) is because an operation on one cursor
> >(active on a certain list object) must be able to interrogate and
possibly
> >update any other cursors (also active on the same list object). With
> >separate cursor objects, the only way to do this is for each cursor to
> >contain a pointer to the list it is active on, and for each list to
contain
> >pointers (perhaps in a linked list) to all the cursors active on it. This
>
> That's correct, but what it ultimately requires is that both lists and
active
> iterators be controlled. I can show the implementation in detail, but the
work
> required is roughly equivalent to providing a body for this package, which
is
> what we were discussing doing in the first place.

I don't think this issue really has anything to do with controlledness
(although the two issues do touch upon one another, they do so only
incidentally). Again, it sounds like you are actually agreeing with me. Are
you?

> Fine rationale aside, it appears we have already reached a consensus on
using
> the controlled iterator approach. The issue under consideration isn't if
someone
> has another approach which they can argue is better. Clearly you feel you
do.
> The issue is what we can move forward with. The approach you describe is
not
> substantially different from the one you presented 2 weeks ago, and the
fact of
> the matter is that people, for whatever reason, have not been rallying
around
> it. I don't see any hope in the tide turning in its favor if we wait
another 2-4
> weeks.

Again, why don't we do it my way, and see how many other people complain?

> The strawman has presented 3 different active iterator approaches (each
> progressively further from my "ideal" btw). The final one seems to be the
one
> people want. I'm not nessecarily any happier about that than you are, but
that's
> the way it has worked out.

So, go for a design you are happier about! :-)

> >[20] What does Splice do? Is it useful?
>
> See *waaay* previously. I cribbed it from the STL. Its essential for
efficiently
> putting two lists together.

Aha! A destructive insert. Handy. (Added to my package ;-)

> >[21] Why do you provide list serialisation (stream read and write)
> >procedures in public, rather than overriding the Read and Write
attributes
> >of the list type in private?
>
> I've had problems (of an exact nature that I forget) when they were
private. So
> that's just become my idiom. It could be that the routines could be moved
to
> just inside of the private section without hurting anything. I'll check it
out
> when I get a chance.

All you have to do is declare in the private part:

   type List is new Ada.Finalization.Controlled with
      record
         ...
      end record;

   procedure Read_List (
         Stream : access Ada.Streams.Root_Stream_Type'Class;
         Item   :    out List );

   procedure Write_List (
         Stream : access Ada.Streams.Root_Stream_Type'Class;
         Item   : in     List );

   for List'Read  use Read_List;
   for List'Write use Write_List;

and then provide bodies for Read_List and Write_List in the package body.
Job done and dusted.

> >Your proposal apparently omits the following vital operations: [22]
testing
> ..
> I don't personally consider any of this "vital", and much of it can be
done just
> fine with an iterator, along with loads of other stuff you haven't thought
of
> but someone somewhere else considers vital. :-)

I readily agree with the point that one could indeed go on and on forever
adding useful operations. But you are wrong that the operations I mentioned
can be done "perfectly well" with an iterator. They cannot: the equivalent
operations done with an iterator would be significantly less efficient (as
well as less convenient).

> >[29] Although you have put some documentation into the spec as comments,
it
> >is not quite as clear or complete as would be ideal. I think it might be
> >helpful if this documentation were separated out into a text (or HTML)
file.
>
> I agree with this wholeheartedly. I already have one volunteer to work up
some
> documentation. Unfortunately, he prefers to work in Word instead of
HTML(yuk).
> But word is (arguably) better than nothing. :-)

Splendid.

> You do point out some issues which I think need to be addressed. But the
only
> ones I'd consider major are issues where it appears we already have a fair
> amount of consensus on. The rest is just naming issues.

Well, to recap: I think the most important consensus is between us two (at
the moment); I think naming issues are pretty important (but true everything
is relative); I think it's important to pin down the spec as best we can
early on, so as not to give the documentor a moving target, and so as not to
give ourselves a moving target writing the sample implementation.

> >Any more thoughts on a (better) name for the project? (Does 'Tenet'
tickle
> >you at all?)
> Perhaps my tonsils a bit. :-)
>
> I'm still stuck on the palindrome issue. Unfortunately, palindromes are
one of
> the tougher word tricks to work out, so there aren't that many to choose
from.
> Since Anna is taken, I'd kind of like "ANA" (if someone can get a decent
acronym
> for it), or "Elle" or "Ele" for personal reasons.

Extended Language Library Endeavour (ELLE) would be fine by me (base package
name 'Elle'). Pretty good, really.

> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

--
Best wishes,
Nick Roberts