List Containers - The Road Ahead

List Containers - The Road Ahead

[Ehud Lamm]

I found many of the psots about the strawman fasniating. Now we should ttry
to move ahead. Here's my suggestion:

We need some central repository. I hope David will agree to host this on
AdaPower.
The repository will include:
- Specs (we have several alternative, and I think we can keep an open mind.
But let's try to keep the number of variations to a minimum).

- Refernce implementations of the specs. These can be contributes by anyone,
but must adhere to the spec. Trying to provide implementations, is the sure
way of finding mistakes in the specs...

- Test code, that uses the containers. If the specs are useful, it should be
easy enough to take some code you have that uses lists, and make it use
"standard" list package.

That's for lists.
To see how the universal the design can be, can someone propose a
Map/Dictionary Strawman?


--
Ehud Lamm   mslamm@mscc.huji.ac.il

Re: List Containers - The Road Ahead

[Ehud Lamm]

I apologize for all the typos in my original message.

Ehud

Re: List Containers - The Road Ahead

[David Botton]

"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9sdpku$eu2$1@news.huji.ac.il...
> We need some central repository. I hope David will agree to host this on
> AdaPower.

Not a problem. What would you like to call the repository?

David Botton

Re: List Containers - The Road Ahead

[Darren New]

David Botton wrote:
> Not a problem. What would you like to call the repository?

How about on sourceforge, with a link from adapower to sourceforge? I
mean, SF already has the CVS setup, the documentation, tar balls, commit
notification mailing lists, discussion mailing lists, bug tracker, etc
etc etc.

Anyway, as far as maps go, it might be a good idea to come to at least a
10% consensus on the list stuff before starting the map stuff, since
there are so many wildly different proposals for lists. It would seem
confusing to have the lists use the 
  type Sequence_Recorder is abstract new Sequence_Reproducer with
private;
stuff and have maps look completely different.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: List Containers - The Road Ahead

[Marin David Condic]

Sourceforge might be an answer *after* some kind of consensus is achieved.
At this point, I'd prefer to deal with a handful of specs only along with
any explanatory "campaign literature" or commentary that may be relevant.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Darren New" <dnew@san.rr.com> wrote in message
news:3BEAB676.8258C23F@san.rr.com...
> David Botton wrote:
> > Not a problem. What would you like to call the repository?
>
> How about on sourceforge, with a link from adapower to sourceforge? I
> mean, SF already has the CVS setup, the documentation, tar balls, commit
> notification mailing lists, discussion mailing lists, bug tracker, etc
> etc etc.
>

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <3BEAB676.8258C23F@san.rr.com>, Darren New says...
>
>David Botton wrote:
>> Not a problem. What would you like to call the repository?
>
>How about on sourceforge, with a link from adapower to sourceforge? I
>mean, SF already has the CVS setup, the documentation, tar balls, commit
>notification mailing lists, discussion mailing lists, bug tracker, etc
>etc etc.

If we can get general agreement on a spec, I have no problem w/ either. But I
don't think we are there yet, so I don't really think we need a multiuser
revision control setup and website quite yet. :-)

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Darren New]

Ted Dennison wrote:
> If we can get general agreement on a spec, I have no problem w/ either. But I
> don't think we are there yet, so I don't really think we need a multiuser
> revision control setup and website quite yet. :-)

OK. I just saw "Specs, Implementations, and Tests, so we can talk about
it", and it sounded like sourceforge. :-) Agreed that we're still
hashing stuff out.

Maybe an AdaWiki would help? Is AdaPower already running Wiki somewhere?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: List Containers - The Road Ahead

[David Botton]

I am sure that if there is a desire for an AdaWiki I can set one up on
AdaPower. Just point me in the direction of the Wiki software, etc.

David Botton

"Darren New" <dnew@san.rr.com> wrote in message
news:3BEC1B65.318C628E@san.rr.com...
> Maybe an AdaWiki would help? Is AdaPower already running Wiki somewhere?

Re: List Containers - The Road Ahead

[Darren New]

David Botton wrote:
> I am sure that if there is a desire for an AdaWiki I can set one up on
> AdaPower. Just point me in the direction of the Wiki software, etc.

This one (in Tcl) got rave reviews. It works quite well, from what I've
seen.
http://twiki.org/cgi-bin/view/Main/TWikiUserQuotes

Actually, it looks like there are lots of Wiki implementations. Take
your pick. :-)
http://directory.google.com/Top/Computers/Software/Groupware/Wiki/

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   You will soon read a generic fortune cookie.

Re: List Containers - The Road Ahead

[Ehud Lamm]

David Botton <David@Botton.com> wrote in message
news:tul4fms8757065@corp.supernews.com...
>
> "Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
> news:9sdpku$eu2$1@news.huji.ac.il...
> > We need some central repository. I hope David will agree to host this on
> > AdaPower.
>
> Not a problem. What would you like to call the repository?
>


I am looking for a good acronym...
I suggest using the phrase "Ada Community Effort" since I find it
motivating. We also need to put "Containers" in the name.

Ehud

Re: List Containers - The Road Ahead

[Nick Roberts]

Extremely Handy Utility Definitions?

:-)

Actually, I think "Dennison" has quite a nice ring to it (seriously). Hmmm,
it's all very subjective. "The Dennison Containers Collection". Well, if
Grady can get away with it, why not Ted? We could start with 'Dennison' as
the base package, and simply change this to 'Ada' if it's accepted (in some
form) into the next revision. I hope T.E.D. agrees! (i.e. can be persuaded
;-) Just an idea.

--
Nick Roberts


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9seqos$4qc$1@news.huji.ac.il...
> David Botton <David@Botton.com> wrote in message
> news:tul4fms8757065@corp.supernews.com...
> >
> > "Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
> > news:9sdpku$eu2$1@news.huji.ac.il...
> > > We need some central repository. I hope David will agree to host this
on
> > > AdaPower.
> >
> > Not a problem. What would you like to call the repository?
>
> I am looking for a good acronym...
> I suggest using the phrase "Ada Community Effort" since I find it
> motivating. We also need to put "Containers" in the name.
>
> Ehud

Re: List Containers - The Road Ahead

[Marin David Condic]

I won't speak for Ted, but he has already expressed a desire that his name
not become the identifier for the collection.

I see nothing wrong with using something like Ada Standard Component Library
(ASCL). Root everything at an empty package called ASCL and you can easily
identify where this stuff comes from.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:9sf0no$12nebe$2@ID-25716.news.dfncis.de...
> Extremely Handy Utility Definitions?
>
> :-)
>
> Actually, I think "Dennison" has quite a nice ring to it (seriously).
Hmmm,
> it's all very subjective. "The Dennison Containers Collection". Well, if
> Grady can get away with it, why not Ted? We could start with 'Dennison' as
> the base package, and simply change this to 'Ada' if it's accepted (in
some
> form) into the next revision. I hope T.E.D. agrees! (i.e. can be persuaded
> ;-) Just an idea.
>

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <9sf48a$ohs$1@nh.pace.co.uk>, Marin David Condic says...
>
>I won't speak for Ted, but he has already expressed a desire that his name
>not become the identifier for the collection.

That's pretty much the case. If the library was entirely my doing, expressing my
personal concept of the ultimate whaterver, I would consider it. However, its
not. What we have right now is what I consider to be the synthesis of the
requirements the community has, as expressed here in c.l.a., for a
general-purpose list package. For all I know, someone could pop in here tomorrow
with a better synthesis, and then it would be truly silly to have my name
attached to it. 

>I see nothing wrong with using something like Ada Standard Component Library
>(ASCL). Root everything at an empty package called ASCL and you can easily
>identify where this stuff comes from.

To offer a lame objection: I don't think ASCL is "clever" enough. I couldn't
really think of a good clever name off the top of my head either though. One of
the reasons I picked "Containers" was that I thought it might be so annoyingly
bland that it would provoke this discussion. :-)

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Marin David Condic]

Well, if we want to have a "Clever" name, then let's just pick a "Marketing"
name with unusual capitalization and some personality. Something like, oh...
eLenore or monIQUE. I'm pretty lousy at this, so go to work on it yourself.
No reason it has to be an acronym for anything.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:b0UG7.19043$xS6.30783@www.newsranger.com...
>
> To offer a lame objection: I don't think ASCL is "clever" enough. I
couldn't
> really think of a good clever name off the top of my head either though.
One of
> the reasons I picked "Containers" was that I thought it might be so
annoyingly
> bland that it would provoke this discussion. :-)
>

Re: List Containers - The Road Ahead

[Ted Dennison]

Marin David Condic wrote:

> Well, if we want to have a "Clever" name, then let's just pick a "Marketing"
> name with unusual capitalization and some personality. Something like, oh...
> eLenore or monIQUE. I'm pretty lousy at this, so go to work on it yourself.
> No reason it has to be an acronym for anything.


I notice that Java add-ons like to expand on the caffinated hot bevarage 
theme. Perhaps we should try to make all Ada add-ons palindromes? :-)

Re: List Containers - The Road Ahead

[Jeffrey Carter]

Ted Dennison wrote:
> 
> I notice that Java add-ons like to expand on the caffinated hot bevarage
> theme. Perhaps we should try to make all Ada add-ons palindromes? :-)

Ah, the Ada Community Effort Container ADTs.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <3BECA762.2FC62F71@acm.org>, Jeffrey Carter says...
>
>Ted Dennison wrote:
>> 
>> I notice that Java add-ons like to expand on the caffinated hot bevarage
>> theme. Perhaps we should try to make all Ada add-ons palindromes? :-)
>
>Ah, the Ada Community Effort Container ADTs.

I was thinking more along the lines of palendromic words or names than acronyms.
Making a palindrome with an acronym is almost cheating. However, this is
interesting.

Perhaps a more serious consideration for a "standard theme" for Ada add-on names
would be names of famous women (preferably in science). But that's perhaps
another thread...

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Nick Roberts]

From a newsletter to the AdaOS group when we were still choosing our name:

-----

Byron had two daughters other than Ada (all three by different mothers).
Ada's half sisters were Allegra and Medora. Allegra was the daughter of
Claire Clairmont; sadly, she died of Typhus at the age of five. I have
not been able to obtain any information about Medora.

Ada's formidable, devoted, and intelligent mother was Annabella
(actually Anne Isabella), nee Milbanke, who separated from Byron shortly
after Ada's birth, and brought up Ada on her own in England. Annabella
can be credited with supporting Ada's interest in mathematics. In the
1850's in England, this was a brave stance; Annabella must have been as
remarkable a woman, in her day, as her daughter.

So, three more possible names: Annabella (suggested to me by Steve
Doran, thanks Steve); Allegra; Medora. Byron originally wanted Allegra
to be called Alba (but Claire insisted on Allegra), so Alba is a fourth
possibility.

-----

Any of these, possibly?

--
Best wishes,
Nick Roberts


"Ted Dennison" <dennison@telepath.com> wrote in message
news:Uz2H7.19771$xS6.32425@www.newsranger.com...
> In article <3BECA762.2FC62F71@acm.org>, Jeffrey Carter says...
> >
> >Ted Dennison wrote:
> >>
> >> I notice that Java add-ons like to expand on the caffinated hot
bevarage
> >> theme. Perhaps we should try to make all Ada add-ons palindromes? :-)
> >
> >Ah, the Ada Community Effort Container ADTs.
>
> I was thinking more along the lines of palendromic words or names than
acronyms.
> Making a palindrome with an acronym is almost cheating. However, this is
> interesting.
>
> Perhaps a more serious consideration for a "standard theme" for Ada add-on
names
> would be names of famous women (preferably in science). But that's perhaps
> another thread...

Re: List Containers - The Road Ahead

[Florian Weimer]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> From a newsletter to the AdaOS group when we were still choosing our name:
> So, three more possible names: Annabella (suggested to me by Steve
> Doran, thanks Steve); Allegra; Medora. Byron originally wanted Allegra
> to be called Alba (but Claire insisted on Allegra), so Alba is a fourth
> possibility.

Viacom Inc. registered an "Allegra" trademark for computer programs in
Germany (and probably the U.S.).  So it wouldn't be a good idea to use
this name. "Alba" is registered an Germany, too (it's the name of a
company, I think it has got to do with gherkins, but there's also a
registration for computer programs).  "Medora" is not available,
either (specifically registered for computer programs).  "Annabella"
is still available.

Re: List Containers - The Road Ahead

[Nick Roberts]

Of course "Annabella" is a bit long!  Back to the drawing board, as they
say.

--
Best wishes,
Nick Roberts



"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:873d3mfj38.fsf@deneb.enyo.de...
> ...
> Viacom Inc. registered an "Allegra" trademark for computer programs in
> Germany (and probably the U.S.).  So it wouldn't be a good idea to use
> this name. "Alba" is registered an Germany, too (it's the name of a
> company, I think it has got to do with gherkins, but there's also a
> registration for computer programs).  "Medora" is not available,
> either (specifically registered for computer programs).  "Annabella"
> is still available.

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <9sk68s$141drd$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>Of course "Annabella" is a bit long!  Back to the drawing board, as they
>say.

Perhaps, but I would like to point out that "Anna" is significantly shorter, and
happens to be a palindrome. :-)

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Perhaps, but I would like to point out that "Anna" is significantly shorter, and
> happens to be a palindrome. :-)

And is already in use for "ANNotated Ada".

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: List Containers - The Road Ahead

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> I notice that Java add-ons like to expand on the caffinated hot
> bevarage theme. Perhaps we should try to make all Ada add-ons
> palindromes? :-)

IMHO, we should just put everything in a GNU Ada Library. ;-)

Re: List Containers - The Road Ahead

[Florian Weimer]

Ted Dennison <dennison@telepath.com> writes:

> I notice that Java add-ons like to expand on the caffinated hot
> bevarage theme. Perhaps we should try to make all Ada add-ons
> palindromes? :-)

IMHO, we should just put everything into a GNU Ada Library. ;-)

Re: List Containers - The Road Ahead

[Jeffrey Carter]

Ehud Lamm wrote:
> 
> I am looking for a good acronym...
> I suggest using the phrase "Ada Community Effort" since I find it
> motivating.

Free, Libre, Yellow, Interesting New Goodies, an Ada Community
Effort--FLYING ACE!

Sorry, I couldn't resist.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: List Containers - The Road Ahead

[Marin David Condic]

Maps should look as much like lists as possible. Similar names &
functionality. It might be better to defer Maps until some kind of decision
is taken about lists.

What might be useful is to put up some competing code with some kind of
"Cast Your Vote" capability. It would also be wise to include in the vote
any already existing packages. The vote probably should not be anonymous so
that stuffing the ballot box is not possible.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9sdpku$eu2$1@news.huji.ac.il...
>
> That's for lists.
> To see how the universal the design can be, can someone propose a
> Map/Dictionary Strawman?
>

Re: List Containers - The Road Ahead

[Ehud Lamm]

Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9semrm$i79$1@nh.pace.co.uk...
> Maps should look as much like lists as possible. Similar names &
> functionality. It might be better to defer Maps until some kind of
decision
> is taken about lists.

Yes and no.
There are subtle differences, and that's why I think working in parallel,
after our initial List discussions, can influence the design of both
containers.

>
> What might be useful is to put up some competing code with some kind of
> "Cast Your Vote" capability. It would also be wise to include in the vote
> any already existing packages. The vote probably should not be anonymous
so
> that stuffing the ballot box is not possible.
>

Votes may be needed later on. I think people will be more inclined to share
if we leave voting for later.

Ehud

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <9semrm$i79$1@nh.pace.co.uk>, Marin David Condic says...
>
>Maps should look as much like lists as possible. Similar names &
>functionality. It might be better to defer Maps until some kind of decision
>is taken about lists.

>"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
>news:9sdpku$eu2$1@news.huji.ac.il...
>>
>> That's for lists.
>> To see how the universal the design can be, can someone propose a
>> Map/Dictionary Strawman?

I'd say that we should at least finish getting the kinks out of the iterators
before trying to synthesize a "Maps" package, since it will need them too.

I started with Lists for 3 reasons:

1)  I've implemented a lot of simple ones myself over the years (there are at
least 2 in OpenToken), so I have a bit of experience and could do it quickly.

2)  I think lists and maps should look consistent, so much of the work in
figuring out how the Maps package works would be done in the process of getting
Lists nailed down.

3)  I didn't think that our discussion of Maps had really progressed to that
point yet. I still don't think we are quite there yet, but it may be time to
start talking more seriously. 

For one small example:

What is the general opinion about using private "key" types in the Maps generic?
Remember that this will mean that "<" is not available. Perhaps that's OK if we
provide a boolean comparison routine as another generic parameter, although that
raises the complexity a bit. But then, should we attempt to make that parmemter
consistent with what is done for the "Sort" routine? How exactly?

We also have yet to have the discussion where someone wants "keys" to be their
own generic package/type that then gets passed into "Sort" generics and into
Maps, and hasn't considered how this complicates use. :-)

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Nick Roberts]

"Ehud Lamm" <mslamm@mscc.huji.ac.il> wrote in message
news:9sdpku$eu2$1@news.huji.ac.il...
> ...
> - Refernce implementations of the specs. These can be contributes by
anyone,
> but must adhere to the spec. Trying to provide implementations, is the
sure
> way of finding mistakes in the specs...

Absolutely right. Excellent idea.

> - Test code, that uses the containers. If the specs are useful, it should
be
> easy enough to take some code you have that uses lists, and make it use
> "standard" list package.

As well as "How To" documentation, giving clear and simple guidelines on how
(best) one would use the proposal.

> That's for lists.
> To see how the universal the design can be, can someone propose a
> Map/Dictionary Strawman?

My proposal already covers (a basic abstract framework for)
content-addressed storage (i.e. it has an index or key type as well as a
data type). However, I recall finding certain corrections that need to be
made (and some improvements).

In general (and therefore in the abstract), any normal container can be made
into a map (mapping say type T1 to type T2) container by containing a T1-T2
duple type:

   type T3 is
      record
         D1: T1;
         D2: T2;
      end record;

and then instantiate the container package with type T3.

Basing things on my proposal now, this points the way to proceed for special
mapping packages:

   generic
      type Source_Type is ...;
      type Target_Type is ...;

   package Magic_Mapping is

      type Mapping_Type is ...; -- concrete type

      ... -- operations on Mapping_Type

      type Mapping_Pair is
         record
            From: Source_Type;
            To: Target_Type;
         end record;

      package Pair_Iteration is new Iteration(Mapping_Pair);

      type Pair_Iterator (Mapping: access Mapping_Type) is
         new Pair_Iteration.Sequence_Reproducer with private;

      procedure Open (Iterator: in out Pair_Iterator);
      procedure Close (Iterator: in out Pair_Iterator);
      ...

   end Magic_Mapping;

This illustrates the alternative technique of an implementation providing an
auxilliary iterator type (rather than the main container type being itself
an iterator). Procedure Open might lock the mapping associated with its
iterator parameter, preventing it from being modified during the iteration;
procedure Close would then unlock the mapping, permitting it to be modified
again. However, this design is certainly not the only one.

Note how this package exports an instantiation of Iteration. This trick has
both advantages and disadvantages, but it means the user (of the package)
has only one instantiation to do:

   package Alchemy is
      new Magic_Mapping(Chemical_Element,Chemical_Element);

The appropriate iterator type is then immediately available for use:

   Melting_Pot_1: aliased Alchemy.Mapping_Type;
   Iterator: Alchemy.Pair_Iterator(Melting_Pot_1'Access);
   Pair: Alchemy.Mapping_Pair;
   ...
   Open(Iterator);
   while not End_of_Data(Iterator) loop
      Read(Iterator,Pair);
      if Pair.From = Lead and Pair.To = Gold then
         raise The_Roof; -- eureka!
      end if;
   end loop;
   Close(Iterator);
   ...

You get the idea (I hope). I have illustrated a concrete mapping (package)
here; it may well be beneficial to devise an abstract mapping (package) on
which to base the concrete ones.

> I apologize for all the typos in my original message.

Taht's prefetcly alirhgt, Ehdu. We undrestnad.

}--|  cheers  ;-)

--
Best wishes,
Nick Roberts

Re: List Containers - The Road Ahead

[Jeffrey Carter]

Ehud Lamm wrote:
> 
> We need some central repository. I hope David will agree to host this on
> AdaPower.
> The repository will include:
> - Specs (we have several alternative, and I think we can keep an open mind.
> But let's try to keep the number of variations to a minimum).

OK. PragmAda contributes PragmARC.List_Unbounded_Unprotected, which is
already at AdaPower.

> 
> - Refernce implementations of the specs. These can be contributes by anyone,
> but must adhere to the spec. Trying to provide implementations, is the sure
> way of finding mistakes in the specs...

OK. PragmAda contributes PragmARC.List_Unbounded_Unprotected, which is
already at AdaPower.

> 
> - Test code, that uses the containers. If the specs are useful, it should be
> easy enough to take some code you have that uses lists, and make it use
> "standard" list package.

OK. PragmAda contributes lsort.adb, which is already at AdaPower.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: List Containers - The Road Ahead

[Ted Dennison]

In article <9sdpku$eu2$1@news.huji.ac.il>, Ehud Lamm says...
>- Refernce implementations of the specs. These can be contributes by anyone,
>but must adhere to the spec. Trying to provide implementations, is the sure
>way of finding mistakes in the specs...

I could do that fairly easily (as it is right now in version 1.1 anyway). But it
appears to still be in a bit of flux, so I'm not sure it would be advisable. I'd
say wait at least another round on it, *then* we make implementation(s), *then*
we worry about Maps and putting it all somewhere semi-official.

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

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: List Containers - The Road Ahead

[Mats Karlssohn]

Well...

Before moving ahead I'll try to add som fuel to this discussion (when
do we reach bonfire level ? :-). On <http://www.geocities.com/tablizer>
there are some quite interesting critisism of OOP in general and some
really thought-worthy stuff about another -ism that the author calls
"Table Oriented Programming" (TOP), I really can't remember where I
found the link, I _hope_ that it is new to atleast some of you.

The author of those pages seems to be a very experienced buissnes-
oriented programmer, and he seems to have experiences and insights
that differs somewhat form what most of us here have. He tends to see
TOP and OOP as each others opposites (spl ?), I lean towards the
opinion that they are actually orthagonal. Therefore I think that
there are lessons to be learned and ideas to steal^H^H^H^H^Hborrow.


While reading the last weeks discussions here, two things have sturck
me:
* It seems that there are some differences in the terminology used. I
  do have some trouble understanding the _exact_ implications and
  differences when you write about lists/deques/maps etc. This may be
  because I'm not english speaking natively. It may also be because
  the terms are used somewhat differently by diccerent languages,
  different writers and different scools.
  Maybe it would be a good idea to define what we are talking about ?
  But OTOH maybe that's what's beeing done ?
* On the implementation level I have been thinking 'mixins, mixins'
  repeatedly.
  Would it be possible to solve for example the streams part of the
  containers using some kind of mixin ?
  OTOH I like the idea of not having to use tagged types, at least
  not for the simple cases. But then, again, maybe we could keep the
  simpelest cases non-tagged and tag the container parts at a higher
  level in the complexity hierarchy.


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809