Re: ASCL a doomed idea?

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

"Mark Lundquist" <mlundquist2@attbi.com> wrote in message
news:7RQP7.4406$Yy.272014@rwcrnsc53...
>
> "Michael Erdmann" <michael.erdmann@snafu.de> wrote in message
> news:mailman.1007670662.18290.comp.lang.ada@ada.eu.org...
> >
> > But as long i can remeber this there is a dicussion about
> > basic containers going on which is find quite useless and
> > which does not help to reach the project objective.
>
> The objective of which project, would that be? :-)
>
> If yours, then it should not be suprising if some other project does not
> help to advance your objective :-)
>
> Not that there is necessarily anything wrong with your project/objective.

I see that Michael has been busy in (at least) the areas of Ada database
interfacing and a project called ACDE, which is about providing components
for building distributed software. Respect.

I see also references to 'ASCL', but I'm not sure whether this is an old
name for ACDE or not, or whether it is currently extant.

Regardless of this, I have thought of a possible alternative name for the
STL-like containers project (effectively) started by TED: "Tenet", from the
Latin "it holds". I think this has the requisite short-and-pithy-ness, and I
don't think it's been used in an Ada context before. It does contain the
word "net", however, so maybe it's not ideal. Does this name tickle anyone's
ticklish bits, at all?

I've been looking carefully at my proposal (NJR 5), Jeffrey Carter's (JC01)
and TED's (1.3), and -- to put it totally bluntly -- I still think mine is
the best so far (I just can't help being perfect ;-) for some fairly
specific reasons:

(1) all my nomenclature is derived directly from Ada.Strings.* wherever
possible, the exceptions being 'cursor', 'cursorage', 'facing', 'prepend',
'split', 'move_cursor', and 'restart' (about which nobody seems to have
argued anyway), and the generic parameter Element_Type, and the function
End_of_*, both of which I have derived from Ada.*_IO;

(2) there are certainly a lot of operations, but (and I have them reviewed
carefully) I believe every single one is justified (including the array
ones), either for reasons of implementational efficiency, or significant
user convenience, or both;

(3) the closed (passive?) iterator included in both JC01 and TED 1.3 is
inferior to the open, container-wide iterator (I have already outlined,
haven't I?) to be added to my proposal, in that it does not permit
restarting within the client procedure, and it does not permit writing at
all.

Having reviewed my design, I have decided not to axe any of the operations,
but to axe two of the parameters: Facing and Offset (except in Move_Cursor).
The complete functionality of the Facing parameter can be reproduced by
implementing a 'smart reverse' operation (so that's two further subprograms
to be added!) with the appropriate semantics. I feel the Offset parameter
(of the cursor-based operations) was overkill, given that you can always
move the cursor to the required position, and then move it back again. Yet
another procedure that needs to be added is a Copy_Cursor. I have rejected
the idea of a separate cursor type (as pointless).

I'm afraid I must say I've been a bit unimpressed about the recent arguments
about the names of the ends of lists. I feel just like Gulliver witnessing,
with incredulity, the arguments between the Lilliputians and the Blefuscuans
about which end of the egg to eat first. Get it together guys, or I'm afraid
Michael's prediction will come true, and I will indeed simply go off and do
it on my own.

--
Sternly,
Nick Roberts