No call for Ada

No call for Ada

[Andrew Carroll]

> ------------------------------
> From: Martin Krischik <krischik@users.sourceforge.net>
> Subject: Re: No call for Ada (was Re: Announcing new
> [snip]
> XML/Ada has complete Unicode support. I am using it for AdaCL.CGI. The
> problem is, as somebody allready pointed out, that you have to collect
half
> a dozend Libs before Ada becomes usefull. What needed is a Unified Ada
> Library which does not need to provide anything new - only put the
> different parts together for a "one click download".
>
> With Regards
>
> Martin

Yes, "one CLICK download".  I don't know that it would be one QUICK
download because I've downloaded about 100MB so far.  Which is about
a 3 day download for me.

Point is, most everyone here has a binding or library or "something" they
want to get out.  An investment so to speak in Ada.  What would happen
if RAPID and AdaGIDE were merged into one?  I would choose GLADE
but I don't think it can spit out MSIL.

How would JGNAT fit in?  Well, can't say for sure yet but I'm sure it could
fit in there somewhere.  Maybe that's the way to go for "Web Services"?
Doesn't Java have SOAP?
(A little soap in your java?  ewe, yuck.  Talk about a platform that
"runs"!)

Right now I have GTK, TCL/TK, RAPID, GLADE, AdaGIDE, MGNAT,
JGNAT, msil2ada, GNAT and JGRASP installed on my computer.  Don't
ask me why.  I am just evaluating all this stuff.  Well, except for GNAT.  I
had A# but it seems to have disappeared...hmmmmm.  Ohh, don't forget
GVD.

Now if we could combine RAPID, GLADE, AdaGIDE (or JGRASP),
MGNAT, GNAT, JGNAT, GVD, AUnit and msil2ada into one tool then
you would pretty much have it all covered as far as "human interaction"
and building/debugging.  You could combine a bunch of bindings like
AWS, GTK, TCL/TK, X11Ada, CORBA, POSIX, AdaCL and
could pull-in/reuse code from the Ada Software Repositories then
you would have a MONSTER.  Whoa ho ho!!!

Who would use it?  Other than me, I don't have a clue.  Who could
understand it?  Well, hopefully everyone who used it.

Monumental task?
Marketable?

What of conversion modules to help companies get into this tool?
Anyone want to write C#2A#?  How about VB.Net2Ada.Net?
Isn't that a market?

Then, the kicker, bust out a blazing fast version of AdaOS.
How many people are on this mailing list?  How many developers?
And that's not enough?

Comments?  Am I insane?


Andrew Carroll
Carroll-Tech
720-273-6814
andrew@carroll-tech.net

Re: No call for Ada

[Pascal Obry]

"Andrew Carroll" <andrew@carroll-tech.net> writes:
> and building/debugging.  You could combine a bunch of bindings like
> AWS, GTK, TCL/TK, X11Ada, CORBA, POSIX, AdaCL and

No, AWS is not a binding. It is a full framework to develop Web
applications. It binds to nothing! It brings a very different way to build
Web applications and all this in Ada.

Just wanted to correct this :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: No call for Ada

[Marius Amado Alves]

> Yes, "one CLICK download".  I don't know that it would be one QUICK
> download because I've downloaded about 100MB so far.  Which is about
> a 3 day download for me.

A CD can be delivered in *one* day to virtually anyone. Never underestimate
the bandwith of the postal service :-)

Re: No call for Ada

[Martin Krischik]

Andrew Carroll wrote:

>> ------------------------------
>> From: Martin Krischik <krischik@users.sourceforge.net>
>> Subject: Re: No call for Ada (was Re: Announcing new
>> [snip]
>> XML/Ada has complete Unicode support. I am using it for AdaCL.CGI. The
>> problem is, as somebody allready pointed out, that you have to collect
> half
>> a dozend Libs before Ada becomes usefull. What needed is a Unified Ada
>> Library which does not need to provide anything new - only put the
>> different parts together for a "one click download".
>>
>> With Regards
>>
>> Martin

> Now if we could combine RAPID, GLADE, AdaGIDE (or JGRASP),
> MGNAT, GNAT, JGNAT, GVD, AUnit and msil2ada into one tool then
> you would pretty much have it all covered as far as "human interaction"
> and building/debugging.  You could combine a bunch of bindings like
> AWS, GTK, TCL/TK, X11Ada, CORBA, POSIX, AdaCL and
> could pull-in/reuse code from the Ada Software Repositories then
> you would have a MONSTER.  Whoa ho ho!!!
> 
> Who would use it?  Other than me, I don't have a clue.  Who could
> understand it?  Well, hopefully everyone who used it.
 
> Monumental task?
> Marketable?

Yes. It has been done for other languages - critics may look at
"http://www.perl.org/" or "http://www.python.org/". 

Yes they have more programmers now - but they both started as a "one man
show".

> Then, the kicker, bust out a blazing fast version of AdaOS.
> How many people are on this mailing list?  How many developers?
> And that's not enough?

I am shure there are enogh here. However, how many are prepared to give up
there privat project and merge it into a unified ada lib.

Mind you, they don't have to. When I did gnat-asis I dicovered the power of
"cvs import". Combining several projects into one with "cvs import" doen't
take that much work.

With Regards

Martin.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Unified Ada library (was: No call for Ada)

[Björn Persson]

Martin Krischik wrote:

> I am shure there are enogh here. However, how many are prepared to give up
> there privat project and merge it into a unified ada lib.

I would. I'd really like to see a unified free Ada library. I only wish 
I had more to contribute. What little I have is a package I'm currently 
hacking on that provides very easy handling of command line parameters 
in a way that I think would be difficult to mimic in most other 
languages. It would be a tiny contribution, but I'd be delighted if it 
were accepted into a larger library.

By the way, I think it would be best to offer both a single big download 
for those who want it and also the same components in separate packages, 
configured to work together with a common directory structure, common 
documentation and so on.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library (was: No call for Ada)

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Martin Krischik wrote:
> 
>> I am shure there are enogh here. However, how many are prepared to give
>> up there privat project and merge it into a unified ada lib.
> 
> I would. I'd really like to see a unified free Ada library. I only wish
> I had more to contribute. What little I have is a package I'm currently
> hacking on that provides very easy handling of command line parameters
> in a way that I think would be difficult to mimic in most other
> languages. It would be a tiny contribution, but I'd be delighted if it
> were accepted into a larger library.

AdaCL allready has a commandline parser. Still, I would not mind if you
merge your ideas in or add  a competing package if it provides a real
alternative.

Download AdaCL from adacl.sf.net and have a look at the AdaCL.GetOpt
package. If you want to join in get a source forge user and drop me a mail.

Once true Unified Ada Library appears then we just move together. 

With Regards

Martin

PS: currently I am using gcc 3.5 - older compilers migh have problems with
the project files. If so, just delete the offendings statements.
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Björn Persson]

Martin Krischik wrote:

> AdaCL allready has a commandline parser. Still, I would not mind if you
> merge your ideas in or add  a competing package if it provides a real
> alternative.
> 
> Download AdaCL from adacl.sf.net and have a look at the AdaCL.GetOpt
> package. If you want to join in get a source forge user and drop me a mail.

I did look at AdaCL before I started. If I understand GetOpt right it 
checks that the command line syntax is okay and delivers the parameters 
one by one as strings and characters. My package takes a different 
approach. It reads all the parameters at once and interprets them 
according to their specified types so that you get the values ready to 
use. It's not for everyone though, since it assumes that parameters may 
be given in any order. It wouldn't be appropriate for cloning the Unix 
"find" command for example. I think it and GetOpt could complement each 
other.

I can't show you the code right now because I'm in the middle of 
rearranging the whole data structure, but here's an example of how to 
use it (though the interface is still in alpha stage). Let's say we're 
writing a program to serve tea:

First we declare all the parameters' names as an enumeration and 
instantiate a generic package with this type:

    type parameters is (tea, volume, sugar, milk, no_milk, customer);
    package handle is new handler(parameters);

Then we need to instantiate a package for each data type that a 
parameter can have, except for boolean and string:

    type teas is (Ceylon, Friesland, green, peppermint);
    type volume is digits 5 range 0.0 .. 10.0;
    package tea_param is new handle.discrete_parameters(teas);
    package natural_param is new handle.discrete_parameters(natural);
    package volume_param is new handle.floating_point_parameters(volume);

Then we define all the parameters with name, type, description, whether 
they may be used once or several times, and whether they are mandatory 
or have defaults. Here the default is 1.65 dl of Ceylon tea with milk 
but no sugar. Customer must always be specified since it has no default 
value. The definitions are placed in an array that is passed to yet 
another generic package:

    spec : handle.parameter_spec :=
      (tea => tea_param.new_definition
         (description => "The taste of dried leaves boiled in water.",
          multiple => false,
          default => Ceylon),
       volume => volume_param.new_definition
         (description => "How much tea you want, in litres.",
          multiple => false,
          default => 0.165),
       sugar => natural_param.new_definition
         (description => "How many lumps of sugar you want.",
          multiple => false,
          default => 0),
       milk => handle.new_boolean_definition
         (description => "Squirted out of a cow.",
          multiple => false,
          default => true),
       no_milk => handle.antonym(milk),
       customer => handle.new_string_definition
         (description => "Who has ordered the tea.",
          multiple => false));

    package analyze is new handle.analyzer(spec);

Finally we call a procedure to parse the command line. If anything is 
wrong it will (optionally) print error messages and then raise an 
exception indicating that the program should terminate:

    analyze.analyze_parameters;

That's all. Now we can access the value of any parameter with a function 
call:

    put_line("Ordered by " & handle.value(customer));
    for lump in 1 .. natural_param.value(sugar) loop

If we want green tea without milk we can call the program like this:

    serve_tea --customer="Tricia McMillan" --tea=green --no_milk

Or for a large cup of Ceylon tea with sugar:

    serve_tea customer=Fenchurch volume=0.25 sugar=2 milk=false

The parameters "help" and "version" are also recognized, so if we type

    serve_tea --help

then analyze_parameters will print something like the following:

    tea=Ceylon|Friesland|green|peppermint  (default: Ceylon)
         The taste of dried leaves boiled in water.

    volume=0.0..10.0  (default: 0.165)
         How much tea you want, in litres.

    sugar=0..2147483647  (default: 0)
         How many lumps of sugar you want.

    milk  (default)
         Squirted out of a cow.
    no_milk
         The opposite of "milk".

    customer=<text>  (mandatory)
         Who has ordered the tea.


> Once true Unified Ada Library appears then we just move together. 

Well if we're going to wait for it to just _appear_ we'll need a lot of 
patience ...

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Martin Krischik wrote:
> 
>> AdaCL allready has a commandline parser. Still, I would not mind if you
>> merge your ideas in or add  a competing package if it provides a real
>> alternative.
>> 
>> Download AdaCL from adacl.sf.net and have a look at the AdaCL.GetOpt
>> package. If you want to join in get a source forge user and drop me a
>> mail.
> 
> I did look at AdaCL before I started. If I understand GetOpt right it
> checks that the command line syntax is okay and delivers the parameters
> one by one as strings and characters. My package takes a different
> approach. It reads all the parameters at once and interprets them
> according to their specified types so that you get the values ready to
> use. It's not for everyone though, since it assumes that parameters may
> be given in any order. It wouldn't be appropriate for cloning the Unix
> "find" command for example. I think it and GetOpt could complement each
> other.

From what I read I think so too. If if you like to join the AdaCL Team
(there are 3 members already) you are welcome.

>> Once true Unified Ada Library appears then we just move together.
> 
> Well if we're going to wait for it to just _appear_ we'll need a lot of
> patience ...

Well the project itsalf is allready there
(http://sourceforge.net/projects/ascl) it just needs some fresh developers.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Björn Persson]

Martin Krischik wrote:

> From what I read I think so too. If if you like to join the AdaCL Team
> (there are 3 members already) you are welcome.

I'll join you soon, but I think I'd better translate comments and 
identifiers to English first. And I see AdaCL uses the Booch components, 
so I should probably switch from Charles to Booch.


>>>Once true Unified Ada Library appears then we just move together.
>>
>>Well if we're going to wait for it to just _appear_ we'll need a lot of
>>patience ...
> 
> 
> Well the project itsalf is allready there
> (http://sourceforge.net/projects/ascl) it just needs some fresh developers.

I think what that kind of project needs is not just some developers 
working on that project. It needs the contribution of just about 
everyone who develops some free Ada library. If a number of ASCL 
developers were to collect libraries from all over the Web and integrate 
them they'd have a lot of work to do just to get familiar with other 
people's code. The original developers of the different libraries could 
probably do the necessary adaptations a lot quicker.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:1ckfc.56157$mU6.232357@newsb.telia.net...

> I'll join you soon, but I think I'd better translate comments and
> identifiers to English first. And I see AdaCL uses the Booch components,
> so I should probably switch from Charles to Booch.

If you're going to switch container libraries, I'd strongly suggest
considering using Ada.Containers, the proposed container library for Ada
200Y. Matt has a reference implementation available (it started out as
Charles, but it's changed a lot, especially after the recent ARG meeting).
It's still a bit of a moving target (especially this week, as we're revising
it based on the meeting decisions), but we're expecting that it will be
included in the standard and thus it will be included with all compilers in
the future. (And since we're keeping it compilable with Ada 95, at least so
far, it probably will be adopted very quickly.)

We don't particularly need libraries that duplicate functionality that is in
the standard (or will be standard), after all.

                   Randy.

Re: Unified Ada library

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Martin Krischik wrote:
> 
>> From what I read I think so too. If if you like to join the AdaCL Team
>> (there are 3 members already) you are welcome.
> 
> I'll join you soon, but I think I'd better translate comments and
> identifiers to English first. And I see AdaCL uses the Booch components,
> so I should probably switch from Charles to Booch.

Difficult to say.

Booch has beed desingened for Ada 95 with flexibility in mind. So you can
specify the storrage strategie. However it is far more difficult to use.
i.E. you need 3 "package .. is new" per component.

Charles is designed from the C++'s STL with easy usage in mind. You need
only one "package .. is new" per component. But advanced Ada features like
storrage pools aren't there.

A Unified Ada Library might just as well have both.

Another poster also jugested "Ada.Components". They have been designed to be
included with every Ada compiler and with simplicity of implementation on
mind. While it is good the have such a component library,  "Ada.Components"
are to limited to replace the more advanced component libraries.

>>>>Once true Unified Ada Library appears then we just move together.
>>>
>>>Well if we're going to wait for it to just _appear_ we'll need a lot of
>>>patience ...
>> 
>> 
>> Well the project itsalf is allready there
>> (http://sourceforge.net/projects/ascl) it just needs some fresh
>> developers.
> 
> I think what that kind of project needs is not just some developers
> working on that project. It needs the contribution of just about
> everyone who develops some free Ada library. If a number of ASCL
> developers were to collect libraries from all over the Web and integrate
> them they'd have a lot of work to do just to get familiar with other
> people's code. The original developers of the different libraries could
> probably do the necessary adaptations a lot quicker.

I think that was the problem leading to there failure. Learning from the
that mistake I would distinquish between "import" and "native" libs. 

The "import" libs I would just "cvs import" and change as little as
possible. Just adding some unified configuration and build management.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Martin Krischik]

Randy Brukardt wrote:

> "Bjï¿œrn Persson" <spam-away@nowhere.nil> wrote in message
> news:1ckfc.56157$mU6.232357@newsb.telia.net...

> If you're going to switch container libraries, I'd strongly suggest
> considering using Ada.Containers, the proposed container library for Ada
> 200Y. Matt has a reference implementation available (it started out as

> We don't particularly need libraries that duplicate functionality that is
> in the standard (or will be standard), after all.

The booch components contain a total of 104 packages. And an extension pack
of another 27 packages within AdaCL.

Ada.Containers are far from providing all the features of the booch
components.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Stephen Leake]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Björn Persson wrote:
> 
> > Martin Krischik wrote:
> > 
> >> From what I read I think so too. If if you like to join the AdaCL Team
> >> (there are 3 members already) you are welcome.
> > 
> > I'll join you soon, but I think I'd better translate comments and
> > identifiers to English first. And I see AdaCL uses the Booch components,
> > so I should probably switch from Charles to Booch.
> 
> Difficult to say.
> 
> Booch has beed desingened for Ada 95 with flexibility in mind. So you can
> specify the storrage strategie. However it is far more difficult to use.
> i.E. you need 3 "package .. is new" per component.

3 instantiations instead of 1 is not _far_ more difficult, in my
opinion. Using C++ is _far_ more difficult :).

If the library is being used in the implementation of AdaCL, needing
three instantiations per component should not be a problem; the people
writing AdaCL should not be novices.

> A Unified Ada Library might just as well have both.

Does that mean you would rename them and "unify" their interfaces, so
it is easy to switch from one to the other?

Simply including Charles and Booch in one distribution is not a
Unified Ada Library.

> Another poster also jugested "Ada.Components". They have been
> designed to be included with every Ada compiler and with simplicity
> of implementation on mind. 

I thought it was ease of use, like Charles. But it hasn't settled down
yet.

> While it is good the have such a component library, "Ada.Components"
> are to limited to replace the more advanced component libraries.

Part of the point of Ada.Components is to encourage a common style for
Ada component libraries. Ideally, everyone that needs components would
use Ada.Components for their simple needs, and then add higher-level
components in the same style, using existing Components as a base
whenever possible, and coordinating with others to maintain a common
style and avoid duplication. Then for Ada 1Z, we'll have more standard
components to add.

That's the hope, anyway :).

Right now, should definitely try to use Ada.Components. If you find a
design flaw that makes them unsuitable for your application, report
it; now is the only chance to fix it! And you may decide you like
them.

> >>>>Once true Unified Ada Library appears then we just move together.
> >>>
> >>>Well if we're going to wait for it to just _appear_ we'll need a lot of
> >>>patience ...
> >> 
> >> 
> >> Well the project itsalf is allready there
> >> (http://sourceforge.net/projects/ascl) it just needs some fresh
> >> developers.
> > 
> > I think what that kind of project needs is not just some developers
> > working on that project. It needs the contribution of just about
> > everyone who develops some free Ada library. If a number of ASCL
> > developers were to collect libraries from all over the Web and integrate
> > them they'd have a lot of work to do just to get familiar with other
> > people's code. The original developers of the different libraries could
> > probably do the necessary adaptations a lot quicker.

To be truly "unified", a set of libraries needs a common architecture.
That is nearly impossible with a random bunch of developers who have
no strong motivation to work together.

When I was doing Windex, there were a couple of other Windows bindings
developed. For each one, I suggested they work with me to develop a
common binding. In each case, it didn't happen, for various good
reasons.

People write libraries because they need them for their own work, or
to satisfy some curiosity that is uniquely theirs. Sacrificing design
principles or productivity to satisfy someone else's needs is very
hard to do!

> I think that was the problem leading to there failure. Learning from the
> that mistake I would distinquish between "import" and "native" libs. 
> 
> The "import" libs I would just "cvs import" and change as little as
> possible. Just adding some unified configuration and build
> management.

Configuration and build management is a tough problem; that's why the
standard Gnu build system, with autoconf, automake, and configure is
so complex. Doing that for a bunch of libraries would certainly be
worth while, but it's a hard job. You'll have to get each developer to
agree to use the common build system.

Making Debian packages is one example of doing common build
management. It doesn't help Windows users, though :).

-- 
-- Stephe

Re: Unified Ada library

[Stephen Leake]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Ada.Containers are far from providing all the features of the booch
> components.

Yes, it is. It's also the next Ada standard, and the core of the
proverbial "Standard Ada Library" that we've all been waiting for. 

The best approach is to use it where you can, and start building more
packages for it, to put in the next standard. 

Ideally, you can adapt your current component libraries to use
Ada.Components as a base without much trouble.

Having said that, I'm waiting for the next iteration of Arg changes
before I start changing SAL to use Ada.Components. But I have
participated in the design discussions.

-- 
-- Stephe

Re: Unified Ada library

[Martin Krischik]

Stephen Leake wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> Ada.Containers are far from providing all the features of the booch
>> components.
> 
> Yes, it is. It's also the next Ada standard, and the core of the
> proverbial "Standard Ada Library" that we've all been waiting for.

I agree with you on that point.
 
> The best approach is to use it where you can, and start building more
> packages for it, to put in the next standard.

In the last version I saw the tag was hidden. So using inheritance for
extension is closed.

> Ideally, you can adapt your current component libraries to use
> Ada.Components as a base without much trouble.

The main component currently used are bounded queues and all Ada.Components
I know of are unbounded. Yes you can use a Vector to create a Queue. And
any unbouded type can be make bounded. However with an hidden tag its extra
effort.
 
> Having said that, I'm waiting for the next iteration of Arg changes
> before I start changing SAL to use Ada.Components. But I have
> participated in the design discussions.

I am there too shouting "indefinite elements" all the time.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Martin Krischik]

Stephen Leake wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> Bjï¿œrn Persson wrote:
>> 
>> > Martin Krischik wrote:

>> Booch has beed desingened for Ada 95 with flexibility in mind. So you can
>> specify the storrage strategie. However it is far more difficult to use.
>> i.E. you need 3 "package .. is new" per component.
> 
> 3 instantiations instead of 1 is not _far_ more difficult, in my
> opinion. Using C++ is _far_ more difficult :).

:-) - But there is a strong movement that components should only need one
instantiation.

>> A Unified Ada Library might just as well have both.
> 
> Does that mean you would rename them and "unify" their interfaces, so
> it is easy to switch from one to the other?

I don't think that is possible. And not needed. Charles and Booch have so
different design philosophies that they can co-exist.
 
>> Another poster also jugested "Ada.Components". They have been
>> designed to be included with every Ada compiler and with simplicity
>> of implementation on mind.
 
> I thought it was ease of use, like Charles. But it hasn't settled down
> yet.

If "ease of use" was main point then they could have just taken Charles with
all its features. But they scaled it down not to overburden the standart.

>> While it is good the have such a component library, "Ada.Components"
>> are to limited to replace the more advanced component libraries.
> 
> Part of the point of Ada.Components is to encourage a common style for
> Ada component libraries.

I know and I hope they succed.

> Right now, should definitely try to use Ada.Components. If you find a
> design flaw that makes them unsuitable for your application, report
> it; now is the only chance to fix it! And you may decide you like
> them.

> To be truly "unified", a set of libraries needs a common architecture.
> That is nearly impossible with a random bunch of developers who have
> no strong motivation to work together.

How did the pyhton and perl guys do it? If I insert my SuSE DVD I have
hundreds of perl and pyhon libraries installed by default. They are made by
indivdualist - yet they come as one or two big rpm package.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
> news:1ckfc.56157$mU6.232357@newsb.telia.net...
> 
>>I'll join you soon, but I think I'd better translate comments and
>>identifiers to English first. And I see AdaCL uses the Booch components,
>>so I should probably switch from Charles to Booch.
> 
> If you're going to switch container libraries, I'd strongly suggest
> considering using Ada.Containers, the proposed container library for Ada
> 200Y. Matt has a reference implementation available (it started out as
> Charles, but it's changed a lot, especially after the recent ARG meeting).
> It's still a bit of a moving target (especially this week, as we're revising
> it based on the meeting decisions), but we're expecting that it will be
> included in the standard and thus it will be included with all compilers in
> the future. (And since we're keeping it compilable with Ada 95, at least so
> far, it probably will be adopted very quickly.)
> 
> We don't particularly need libraries that duplicate functionality that is in
> the standard (or will be standard), after all.
> 
>                    Randy.

It is a good effort, and I think everyone welcomes that support in the
standard. However, it is still lacking some commonly needed components
like Trees. I don't remember if Charles has them, but the BC smart pointers
are handy as well.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Unified Ada library

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
 

: However, it is still lacking some commonly needed components
: like Trees.

What kind of trees do you need?
For what operations?
Some Charles components are _based_ on trees.

Re: Unified Ada library

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
 
: In the last version I saw the tag was hidden. So using inheritance for
: extension is closed.

I remember this has been discussed. Charles is to be used differently.
It doesn't always seem to think about Charles components in Booch terms.

 
: I am there too shouting "indefinite elements" all the time.

Yeah. Does everyone add one level of indirection to solve this?

Re: Unified Ada library

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: 
: I am there too shouting "indefinite elements" all the time.
 
Seems like you have been heard :-)

generic

   type Key_Type (<>) is private;

   ...

package AI302.Containers.Indefinite_Hashed_Maps is

Re: Unified Ada library

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
 
: But advanced Ada features like
: storrage pools aren't there.

Hm. Do you need storage management for your own data
or do you wish to specify a pool for the components' "infrastructure"?
In the first case you are in command...

 
: "Ada.Components"
: are to limited to replace the more advanced component libraries.

Does it render them useless? 
(For example, looking at the 10 Boost things to be added to the
next C++, I find some of them, uhm, conventient like Perl regular
excessive syntax.)

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>  
> : I am there too shouting "indefinite elements" all the time.
> 
> Yeah. Does everyone add one level of indirection to solve this?

I tend to abstract away the indefiniteness, then use the abstraction for 
the element. For example, if I want a structure of Strings, I use 
[Un]Bounded_String as the element (in this case the abstraction has been 
done for me). This generally has important benefits beyond the use of 
the structure. Consider manipulating "access String" values everywhere, 
instead of using Unbounded_String. The abstraction is cleaner, simpler, 
and safer.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Unified Ada library

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
: I tend to abstract away the indefiniteness, then use the abstraction for 
: the element. [...]
: The abstraction is cleaner, simpler, and safer.

Thanks, that makes me think again. I'm still trying to find
a way to have a constructor subprogram with arguments that
must be run for proper initialisation. Is there a way this
can be forced without introducing indefiniteness?



-- Georg

Re: Unified Ada library

[Randy Brukardt]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:c5mgs2$er$2@a1-hrz.uni-duisburg.de...
> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : I am there too shouting "indefinite elements" all the time.
>
> Yeah. Does everyone add one level of indirection to solve this?

For what it's worth, you don't have to shout anymore. The ARG spent 6 hours
on containers in Phoenix, and one of the many decisions was to include the
indefinite versions of the containers. Indeed, pretty much everything that
was discussed on Ada-Comment was added (Lists, set operations, and more).

Matt, Tucker, and I are working on a new draft with all of the changes
included; hopefully that will be done this week. (You can see the discussion
in the ARG minutes; the draft for the Phoenix meeting is up on the web
site.)

                   Randy.

Re: Unified Ada library

[Stephen Leake]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Stephen Leake wrote:
> 
> > Martin Krischik <krischik@users.sourceforge.net> writes:
> > 
> >> Björn Persson wrote:
> >> 
> >> > Martin Krischik wrote:
> 
> >> Booch has beed desingened for Ada 95 with flexibility in mind. So you can
> >> specify the storrage strategie. However it is far more difficult to use.
> >> i.E. you need 3 "package .. is new" per component.
> > 
> > 3 instantiations instead of 1 is not _far_ more difficult, in my
> > opinion. Using C++ is _far_ more difficult :).
> 
> :-) - But there is a strong movement that components should only need one
> instantiation.

Hmm. I hear some people saying that, in the context of Ada.Components,
and in Grace. In both cases, the justification is "make it easy for
novices to use".

SAL is _not_ designed with that criteria; instead, the main goal is
"exploit the full power of Ada, in a consistent architecture".

> >> A Unified Ada Library might just as well have both.
> > 
> > Does that mean you would rename them and "unify" their interfaces, so
> > it is easy to switch from one to the other?
> 
> I don't think that is possible. And not needed. Charles and Booch have so
> different design philosophies that they can co-exist.

Then it is not a "unified" library; it is a "collection" of libraries.

Not a big deal, but it is important to be clear what you are doing.

And there is overlap between Charles and Booch. If I start an
application with Charles list, but then want to switch to Booch trees
(because they are better in some way for my application than Charles trees),
that's harder than it would be if the same feature was in Charles in
the first place.

> >> Another poster also jugested "Ada.Components". They have been
> >> designed to be included with every Ada compiler and with simplicity
> >> of implementation on mind.
>  
> > I thought it was ease of use, like Charles. But it hasn't settled down
> > yet.
> 
> If "ease of use" was main point then they could have just taken Charles with
> all its features. But they scaled it down not to overburden the standart.

The "overburden" was on the Arg in analyzing the proposal, not on the
implementers. Everyone expects the implementations to be pretty
straightforward.

> > To be truly "unified", a set of libraries needs a common architecture.
> > That is nearly impossible with a random bunch of developers who have
> > no strong motivation to work together.
> 
> How did the pyhton and perl guys do it? If I insert my SuSE DVD I have
> hundreds of perl and pyhon libraries installed by default. They are made by
> indivdualist - yet they come as one or two big rpm package.

Yes. But do they truly form a unified architecture? Or are they just
collections of individual things, each differing in user interface
conventions? I suspect the later, but I don't use them, so I don't know.

GNAT comes with a pretty large library, as well. It is noticably less
clean, less well organized, than the Ada standard. Producing unified
design is expensive.

-- 
-- Stephe

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> Thanks, that makes me think again. I'm still trying to find
> a way to have a constructor subprogram with arguments that
> must be run for proper initialisation. Is there a way this
> can be forced without introducing indefiniteness?

I'm not sure what you mean. Can you provide an example?

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Unified Ada library

[Jeffrey Carter]

Randy Brukardt wrote:

> For what it's worth, you don't have to shout anymore. The ARG spent 6 hours
> on containers in Phoenix, and one of the many decisions was to include the
> indefinite versions of the containers. Indeed, pretty much everything that
> was discussed on Ada-Comment was added (Lists, set operations, and more).
> 
> Matt, Tucker, and I are working on a new draft with all of the changes
> included; hopefully that will be done this week. (You can see the discussion
> in the ARG minutes; the draft for the Phoenix meeting is up on the web
> site.)

I'm in the Phoenix area. I wish I'd known. Unlike Heaney, I can't afford 
to fly all over the world promoting my view of Ada. Are these things 
open to the public?

Regarding the minutes, I mostly like what I see (other than the horrible 
error of not calling it Unbounded_Array). I have a nit: The minutes say, 
"Pascal wonders if 'and' and 'or' would be better for Union and 
Intersection." This implies that Union is equivalent to "and" and 
Intersection to "or"; actually it's the other way around.

It's because even experienced people such as Pascal get these wrong that 
I think even a simple bit-mapped set should include such operations, 
rather than relying on the user creating arrays of Boolean and applying 
Boolean operations on them directly.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16

Re: Unified Ada library

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:eHFfc.12113$A_4.4564@newsread1.news.pas.earthlink.net...
...
> I'm in the Phoenix area. I wish I'd known. Unlike Heaney, I can't afford
> to fly all over the world promoting my view of Ada. Are these things
> open to the public?

By invitation only. But I doubt that you would have been turned down had you
asked. (New opinions never hurt.)

> Regarding the minutes, I mostly like what I see (other than the horrible
> error of not calling it Unbounded_Array). I have a nit: The minutes say,
> "Pascal wonders if 'and' and 'or' would be better for Union and
> Intersection." This implies that Union is equivalent to "and" and
> Intersection to "or"; actually it's the other way around.
>
> It's because even experienced people such as Pascal get these wrong that
> I think even a simple bit-mapped set should include such operations,
> rather than relying on the user creating arrays of Boolean and applying
> Boolean operations on them directly.

I suspect that it is more likely that the note taker (me) got it backwards
writing it down. And no one caught it.

                Randy.

Re: Unified Ada library

[Georg Bauhaus]

Randy Brukardt <randy@rrsoftware.com> wrote:
: 
: Matt, Tucker, and I are working on a new draft with all of the changes
: included; hopefully that will be done this week. (You can see the discussion
: in the ARG minutes; the draft for the Phoenix meeting is up on the web
: site.)

Reading the discussion I have become curious about the extent that
the power of STL-iterators/cursors is appreciated? (Please excuse
the bold statement.) That is, the technique of generic algorithms,
adaptors, ...

If typical cursor use is supposed to be "Exists(Position)" in a loop
iteration scheme, it is an interesting view but shouldn't "Exists"
be a prime example of a function that can be flexibly defined in terms
of Cursors/Iterators? Something Like

   generic
      stop: Cursor_Type;
   function generic_exists (position: Cursor_Type) return Boolean;
   --   false when position = stop

   ...


   declare
     it: Cursor_Type := first(a_cont);

     function Exists is new generic_exists(find(a_cont, a_value));
   begin
     while Exists(it) loop
        ...
     end loop;
   end;


Besides that, "exists" is frequently found in data structure
libraries of functional languages, but with a different meaning,
here is OCaML:

# List.exists ;;
- : ('a -> bool) -> 'a list -> bool = <fun>

(Let alone SETL2 where "exists" triggers iteration behind the scene :-)



-- Georg

Re: Unified Ada library

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
: Georg Bauhaus wrote:
: 
:> Thanks, that makes me think again. I'm still trying to find
:> a way to have a constructor subprogram with arguments that
:> must be run for proper initialisation. Is there a way this
:> can be forced without introducing indefiniteness?
: 
: I'm not sure what you mean. Can you provide an example?


One real life problem asks me to make constant links between existing
items, and to make a collection of such links.  The items are read
at run time, and the links will be of varying kinds. So
I started with something like

      type Link(<>) is tagged limited private;

      function make(source, destination: access Node) return Link;

The private full view of Link has the same parenthesis as make,
i.e. access discriminants.
So far so good, but Link is now both indefinite and limited,
the make function is useless (before Ada 200Y?), although by
intention it is required.

The next best thing I could think of was to simply make

      type Link is tagged private;

      function make ...;

and use access constant Node pointers as components + programmer
discipline.

(I have also tried to turn Link into an ML style generic constructor
procedure,
   type Link is access procedure ...;
but the 'access values to procedure instances would refer to
subprograms at a deeper level than the access type "Link".)

I have a vague idea that another option is to use a Link subprogram,
and store linking information in the Nodes or in a backing structure.
(Something similar is done anyway, in a graphs section.) 
Since the links will be used with an algorithm that assumes linked pairs,
this will require an interface adapting the Node data. Maybe...

And last, I'm playing with moving the polymorphism of the links
to a generic formal.  Link will then be non-tagged and will have a
component of the generic formal type. Or maybe its 'class. Phew.

   generic
      type Arc is new Edge with private;
   package Links is

     type Link(source, destination: Node_Ptr := null) is private;
     -- or type Link(<>) is private;  if containers permit indefinite types

     function make ...;
     function connection(lnk: Link) return Arc;

   private
     type Link(source, destination: Node_Ptr := null) is
       record
          connection: Arc;
       end record;

   end Links;



-- Georg

Re: Unified Ada library

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>  
> : But advanced Ada features like
> : storrage pools aren't there.
> 
> Hm. Do you need storage management for your own data
> or do you wish to specify a pool for the components' "infrastructure"?
> In the first case you are in command...

For a while I used a garbage collector for which I needed to specify
storrage pools.

However, I have extendeded the booch components to provide support for
indefinite objects - which is far more helpfull.

> : "Ada.Components"
> : are to limited to replace the more advanced component libraries.
> 
> Does it render them useless?

No of course not. For many basic features they are quite OK. And they have
support for indefinite objects ;-).

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Jano]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Randy Brukardt dice...
> "Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
> news:1ckfc.56157$mU6.232357@newsb.telia.net...
> 
> > I'll join you soon, but I think I'd better translate comments and
> > identifiers to English first. And I see AdaCL uses the Booch components,
> > so I should probably switch from Charles to Booch.
> 
> If you're going to switch container libraries, I'd strongly suggest
> considering using Ada.Containers, the proposed container library for Ada
> 200Y. 

Link, please?

Re: Unified Ada library

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> wrote in message news:<eHFfc.12113$A_4.4564@newsread1.news.pas.earthlink.net>...
> 
> I'm in the Phoenix area. I wish I'd known. Unlike Heaney, I can't afford 
> to fly all over the world promoting my view of Ada. Are these things 
> open to the public?

I wish I were as rich as Jeff thinks I am.  (Believe me, I'm not.)  I
flew to Phoenix at my own expense, because I felt it was important for
the author of the container proposal to be there to participate in the
discussion of AI-302.

If Pascal wants me there, I will do the same for the next ARG meeting
in Spain (I'll be at the Ada-Europe conference anyway, to present a
paper and a tutorial), and for the meeting after that in Wisconsin.

My attendance at the ARG meeting in Phoenix had nothing to do with
"promoting my view of Ada."  I have much better things to do with my
time and money than that.


> Regarding the minutes, I mostly like what I see (other than the horrible 
> error of not calling it Unbounded_Array). I have a nit: The minutes say, 
> "Pascal wonders if 'and' and 'or' would be better for Union and 
> Intersection." This implies that Union is equivalent to "and" and 
> Intersection to "or"; actually it's the other way around.

I just checked the AI-302 reference implementation: "and" is a
renaming of Intersectiona and "or" is a renaming of Union.

But you don't have to take my word for it.  Just browse the latest
snapshot of the source yourself:

<http://charles.tigris.org/source/browse/charles/src/ai302/>


> It's because even experienced people such as Pascal get these wrong that 
> I think even a simple bit-mapped set should include such operations, 
> rather than relying on the user creating arrays of Boolean and applying 
> Boolean operations on them directly.

There are no bit-mapped sets in AI-302.  Elements are ordered
according to a less-than relation.  You can browse to source (see the
link above) to see how set interestion, union, etc, are implemented.

Regards,
Matt

Re: Unified Ada library

[Matthew Heaney]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:<jJyfc.22340$2Z6.944587@news20.bellglobal.com>...
> 
> It is a good effort, and I think everyone welcomes that support in the
> standard. However, it is still lacking some commonly needed components
> like Trees. I don't remember if Charles has them, but the BC smart pointers
> are handy as well.

Neither Charles nor AI-302 has "trees" specifically.  Rather, we took
a more high-level approach and used a tree to implement the ordered
set.

Please peruse the source of the ordered set, and let me know what you
can do with a tree that you can't do with an ordered set.

<http://charles.tigris.org/source/browse/charles/src/ai302/>

Regards,
Matt

Re: Unified Ada library

[Randy Brukardt]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:c5nfmv$hf4$1@a1-hrz.uni-duisburg.de...
> Randy Brukardt <randy@rrsoftware.com> wrote:
> :
> : Matt, Tucker, and I are working on a new draft with all of the changes
> : included; hopefully that will be done this week. (You can see the
discussion
> : in the ARG minutes; the draft for the Phoenix meeting is up on the web
> : site.)
>
> Reading the discussion I have become curious about the extent that
> the power of STL-iterators/cursors is appreciated? (Please excuse
> the bold statement.) That is, the technique of generic algorithms,
> adaptors, ...
>
> If typical cursor use is supposed to be "Exists(Position)" in a loop
> iteration scheme, it is an interesting view but shouldn't "Exists"
> be a prime example of a function that can be flexibly defined in terms
> of Cursors/Iterators? Something Like

I have no idea of what you're talking about here, because Exists() is
supposed to be a function of a cursor. So claiming that somehow there is
difference between Exists() and cursors makes no sense.

The reason for replacing Null_Cursor with Exists() is simply that there is a
desire that there is not necessarily a single null value for cursors.

In any case, there are technical problems with this change that is holding
up the completion of the new draft of AI-302. Just because the ARG asked for
something during a discussion doesn't mean that it is actually possible to
do.

                       Randy.

Re: Unified Ada library

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
>  
> 
> : However, it is still lacking some commonly needed components
> : like Trees.
> 
> What kind of trees do you need?
> For what operations?
> Some Charles components are _based_ on trees.

I need BC.Containers.Trees.Multiway trees ;-)

Being based upon trees, and exposing a tree based API
are different. The last time I looked, this functionality
is missing in Charles.

Why do I need it?  I needed to build and use a parse tree
with the help of ayacc. Multiway trees work great for
this sort of thing. No pointers required either, since
tree sharing is already builtin.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Unified Ada library

[Warren W. Gay VE3WWG]

Matthew Heaney wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message news:<jJyfc.22340$2Z6.944587@news20.bellglobal.com>...
> 
>>It is a good effort, and I think everyone welcomes that support in the
>>standard. However, it is still lacking some commonly needed components
>>like Trees. I don't remember if Charles has them, but the BC smart pointers
>>are handy as well.
> 
> Neither Charles nor AI-302 has "trees" specifically.  Rather, we took
> a more high-level approach and used a tree to implement the ordered
> set.
> 
> Please peruse the source of the ordered set, and let me know what you
> can do with a tree that you can't do with an ordered set.
> 
> <http://charles.tigris.org/source/browse/charles/src/ai302/>

Hi Matt:

I responded to this issue in a prior post today.
In short, I need "tree sharing" and a "tree API" to
work with a parse tree (one example). If you want to fully
understand why, use BC.Containers.Tree.Multiway, and think
about how you would use this with ayacc.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Unified Ada library

[Matthew Heaney]

Jano <nono@unizar.es> wrote in message news:<MPG.1aea1f788efb778c9896e6@news.able.es>...
> Randy Brukardt dice...
> > 
> > If you're going to switch container libraries, I'd strongly suggest
> > considering using Ada.Containers, the proposed container library for Ada
> > 200Y. 
> 
> Link, please?

<http://charles.tigris.org/source/browse/charles/src/ai302/>

-Matt

Re: Unified Ada library

[Jeffrey Carter]

Randy Brukardt wrote:

> "Jeffrey Carter" <spam@spam.com> wrote in message
> news:eHFfc.12113$A_4.4564@newsread1.news.pas.earthlink.net...
> ...
>>It's because even experienced people such as Pascal get these wrong that
>>I think even a simple bit-mapped set should include such operations,
>>rather than relying on the user creating arrays of Boolean and applying
>>Boolean operations on them directly.
> 
> 
> I suspect that it is more likely that the note taker (me) got it backwards
> writing it down. And no one caught it.

Well, then, it's because even experienced people such as Randy get these 
wrong ... :)

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

Re: Unified Ada library

[Jeffrey Carter]

Matthew Heaney wrote:

> I wish I were as rich as Jeff thinks I am.  (Believe me, I'm not.)  I
> flew to Phoenix at my own expense, because I felt it was important for
> the author of the container proposal to be there to participate in the
> discussion of AI-302.
> 
> If Pascal wants me there, I will do the same for the next ARG meeting
> in Spain (I'll be at the Ada-Europe conference anyway, to present a
> paper and a tutorial), and for the meeting after that in Wisconsin.

I didn't say Matt was rich, merely that he could afford to fly to places 
around the world. Given his statements that he could afford to fly to 
Phoenix, Europe, and Wisconsin this year, and the fact that he attended 
Ada-Europe as a presenter last year, I think that is an accurate 
statement. I haven't been able to afford to attend a conference for a 
long time.

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

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> One real life problem asks me to make constant links between existing
> items, and to make a collection of such links.  The items are read
> at run time, and the links will be of varying kinds. So
> I started with something like
> 
>       type Link(<>) is tagged limited private;
> 
>       function make(source, destination: access Node) return Link;
> 
> The private full view of Link has the same parenthesis as make,
> i.e. access discriminants.
> So far so good, but Link is now both indefinite and limited,
> the make function is useless (before Ada 200Y?), although by
> intention it is required.

I guess I'm kind of thick. I don't understand why you think Link needs 
to be indefinite, nor why you want it tagged.

> The next best thing I could think of was to simply make
> 
>       type Link is tagged private;
> 
>       function make ...;
> 
> and use access constant Node pointers as components + programmer
> discipline.

Why is programmer discipline needed? The client does not have access to 
the components, and you don't seem to have a problem with multiple 
references if the client copies values of Link, since these contain 
pointers to existing items (assuming I understand that phrase correctly).

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

Re: Unified Ada library

[Björn Persson]

Randy Brukardt wrote:

> If you're going to switch container libraries, I'd strongly suggest
> considering using Ada.Containers, the proposed container library for Ada
> 200Y.

I had forgotten about that. Yes, if Ada.Containers becomes standard I 
should probably use that, but not until it has stabilized I think. I'm 
not experienced enough to say what is good or flawed design anyway, so I 
couldn't provide any feedback about the design of Ada.Containers. So 
since I expect Ada.Containers to be more similar to Charles than to 
Booch I think I'll stick to Charles for now.

Actually, I need a kind of ordered many-to-one mapping. I need to map 
several keys to the same value (the same object, not identical values), 
and iterate over the values (not the keys) in the same order that they 
were added in. I guess that's too specialized for Ada.Containers. I 
didn't find that in Booch either, so right now I have my own ad-hoc 
solution for that, built around a dynamic vector from Charles.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:D3_fc.13460$k05.5988@newsread2.news.pas.earthlink.net...
> Randy Brukardt wrote:
>
> > "Jeffrey Carter" <spam@spam.com> wrote in message
> > news:eHFfc.12113$A_4.4564@newsread1.news.pas.earthlink.net...
> > ...
> >>It's because even experienced people such as Pascal get these wrong that
> >>I think even a simple bit-mapped set should include such operations,
> >>rather than relying on the user creating arrays of Boolean and applying
> >>Boolean operations on them directly.
> >
> >
> > I suspect that it is more likely that the note taker (me) got it
backwards
> > writing it down. And no one caught it.
>
> Well, then, it's because even experienced people such as Randy get these
> wrong ... :)

It's quite a trick to take 35 pages of notes and participate in discussions
at the same time. I find that I've frequently written down nonsense because
of two trains of thought crossing. The real job of making the minutes is to
decode the nonsense. But I don't always recognize nonsense when I re-read
it...

                     Randy.

Re: Unified Ada library

[Simon Wright]

Bjï¿œrn Persson <spam-away@nowhere.nil> writes:

> I'll join you soon, but I think I'd better translate comments and
> identifiers to English first. And I see AdaCL uses the Booch
> components, so I should probably switch from Charles to Booch.

I think, as Randy said, that a new project should definitely start
with Ada.Containers (that is right, someone mentioned
Ada.Components? I see the source is AI302.Containers).

Ada.Containers is not expected to solve every problem; for example,
they don't include any locking, for essentially the same reason as
locking was removed from the BCs: there's no way to provide other than
the most simple features, because the requirements are so variable.

My current work project has a lot of investment in some of the BCs,
and really needs the Bounded versions and the control over storage
pools. Aside from that, it would be hard to change container library
because of the investment in code that uses library features (allowing
this was a mistake, with hindsight).

Other people might find SAL, or the BC extensions in AdaCL, just what
they need.

If you can find a ready-made library that has the exact feature you
need, then go for it. But if you need to modify it to do what you
want, consider using Ada.Containers; if nothing else, it'll add to the
pool of experience.

Ada.Containers isn't extensible in the same way that the BCs are. But
if you look at for example BC.Containers.Collections.Ordered.Unmanaged,
you'll see that it was a lot of work to provide what you/I might have 
hoped  would be simple. The major reuse area in the BCs is in the 
lower-level implementation packages, BC.Support.Bounded for example,
and using Ada.Containers as the implementation technology for your
specific containers is a similar approach.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Unified Ada library

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
: Georg Bauhaus wrote:
: 
:> 
:>       type Link(<>) is tagged limited private;
:> 
:>       function make(source, destination: access Node) return Link;
: 
: I guess I'm kind of thick. I don't understand why you think Link needs 
: to be indefinite, nor why you want it tagged.

(Sorry for being unclear, I'm probably too deep into this to
have a clear view.)
My reason to choose an indefinite type in this case has been that
I wan't a construtor to initialise the components of Link
objects. Default values won't do because they are not known
until runtime. How to express this requirement so that the
compiler will check?

The type is tagged because I wanted objects to be polymorphic,
for example, plain links, weighted links, ...
Now as I write this, there are good old variant records...

:> The next best thing I could think of was to simply make
:> 
:>       type Link is tagged private;
:> 
:>       function make ...;
:> 
:> and use access constant Node pointers as components + programmer
:> discipline.
: 
: Why is programmer discipline needed?

The programmer (me in this case, but who knows) can create objects
of type Link without calling make for initialisation, but make
is a must for proper initialisation.



thanks,
-- Georg

Re: Unified Ada library

[Georg Bauhaus]

Randy Brukardt <randy@rrsoftware.com> wrote:
: I have no idea of what you're talking about here, because Exists() is
: supposed to be a function of a cursor. So claiming that somehow there is
: difference between Exists() and cursors makes no sense.
: 
: The reason for replacing Null_Cursor with Exists() is simply that there is a
: desire that there is not necessarily a single null value for cursors.

I was thinking of Cursors as the pointer-like things that they
are in AI302 (and STL), if my understanding is correct.
Say I have an algorithm operating on the elements of some data
structure using two or more cursors, like approaching some "middle"
element "pointed to" by some other cursor from "two sides".
Sort of
    p := find(s, v);
    while j < p and p < k loop
       ...
       j := compute_next(j);
       k := compute_next(k);
    end loop;

If I wanted to express the condition using Exists with the cursors
j and k respectively, woudn't the cursors j and k have to "know" that
they "exist until p"?
Therefore I was wondering whether this isn't a different approach
to Cursors/Iterators, namely Cursors in the sense of objects, rather
than in the sense of pointers.

Re: Unified Ada library

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Reading the discussion I have become curious about the extent that
> the power of STL-iterators/cursors is appreciated? (Please excuse
> the bold statement.) That is, the technique of generic algorithms,
> adaptors, ...

We didn't get into the generic algorithms, because it was outside of the
scope of the AI.  Charles has some generic algorithms (I still have some
work to do there), but I didn't include them in my original proposal, in
order to keep its size small.  (My original proposal was 150 pgs. long,
even without generic algorithms.)


> If typical cursor use is supposed to be "Exists(Position)" in a loop
> iteration scheme, it is an interesting view but shouldn't "Exists"
> be a prime example of a function that can be flexibly defined in terms
> of Cursors/Iterators?

The predicate Exists is used to test whether you've fallen off the end:

    procedure Op (L : in List) is
       I : Cursor := First (L);
    begin
       while Exists (I) loop
         E := Element (I);
         Next (I);
       end loop;
    end;


Some of the semantics of cursor behavior still have to be clarified, but
you might be able to use a Charles-like algorithm like this:

   proceudre Op (L : in List) is
      I : Cursor := First (L);
      J : constant Cursor := Next (Last (L));
   begin
      Algorithm (I, J);
   end;

However, it's still not clear whether the expression Next (Last (L)) is
even defined for an empty list.  (I think it should be, but it's up the
ARG to decide.)

I don't much like the Exists function.  I was hoping we could compromise
by defining a deferred constant called Null_Cursor, and defining Next
(Last (Container)) to return the value Null_Cursor.  But I lost that
battle and Null_Cursor is gone.  Oh, well.


-Matt

Re: Unified Ada library

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> I was thinking of Cursors as the pointer-like things that they are in
> AI302 (and STL), if my understanding is correct.

I think a cursor should be a modeled explicitly as a pointer, but the
ARG wanted a more abstract approach.  However, you can probably do what
you're trying to do; see below.


> Say I have an algorithm operating on the elements of some data
> structure using two or more cursors, like approaching some "middle"
> element "pointed to" by some other cursor from "two sides".

That makes sense; it's how an algorithm to reverse a sequence would be
implemented, for example.


> Sort of
>     p := find(s, v);
>     while j < p and p < k loop
>        ...
>        j := compute_next(j);
>        k := compute_next(k);
>     end loop;

The only cursor for which "<" would make sense is for a random-access
container like a vector.  I wanted "<", "+", "-", etc operators for
vector cursors but that idea got vetoed.  In any event you'd have to
write the algorithm above like this:

   P := Find (List, E);
   J := First (List);
   K := Last (List);

   while J /= P and then K /= P loop
      ...
      Next (J);
      Previous (K);
   end;

(At least I think this is what you meant.)

I recommend you simply download the reference implementation (note that
it's going to get updated this weekend, to sync it up with the latest
draft AI), and then write some toy programs.

<http://charles.tigris.org/source/browse/charles/src/ai302/>



> If I wanted to express the condition using Exists with the cursors
> j and k respectively, woudn't the cursors j and k have to "know" that
> they "exist until p"?

The predicate function Exists just tells you whether you're pointing to
an element in the container.  I don't think Exists is appropriate for
your algorithm, since at every point you're pointing to an element in
the container.  (But I could be wrong -- I might have misinterpreted
your example.)


> Therefore I was wondering whether this isn't a different approach to
> Cursors/Iterators, namely Cursors in the sense of objects, rather than
> in the sense of pointers.

A cursor just carries around enough state to interrogate an element in
the container.

-Matt

Re: Unified Ada library

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> However, I have extendeded the booch components to provide support for
> indefinite objects - which is far more helpfull.

I'll be adding support for indefinite element types to Charles at some
point (as soon as all the AI-302 activity dies down a bit), but in the
meantime the AI-302 reference implementation already has it.

<http://charles.tigris.org/source/browse/charles/src/ai302/>

Be aware that what's there now might be slightly out of date.  I still
need to update the reference implementation to match the latest draft
AI.

-Matt

Re: Unified Ada library

[Matthew Heaney]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> I responded to this issue in a prior post today.  In short, I need
> "tree sharing" and a "tree API" to work with a parse tree (one
> example). If you want to fully understand why, use
> BC.Containers.Tree.Multiway, and think about how you would use this
> with ayacc.

I see what you're getting at, but the current AI is very modest, and
therefore doesn't support recursive data structures.

The tree container is a good idea, though, and we should keep it in mind
for inclusion in a secondary standard.

-Matt

Re: Unified Ada library

[Matthew Heaney]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Actually, I need a kind of ordered many-to-one mapping. I need to map
> several keys to the same value (the same object, not identical
> values), and iterate over the values (not the keys) in the same order
> that they were added in. I guess that's too specialized for
> Ada.Containers. I didn't find that in Booch either, so right now I
> have my own ad-hoc solution for that, built around a dynamic vector
> from Charles.

It sounds like you need a multimap, with an element that's a pointer to
the object shared among equal keys.

Charles has direct support for multimaps.  AI-302 does not.  To get a
multimap-like container from AI-302 components, you'll have to use a
(hashed) map with a vector or list as its element.

-Matt

Re: Unified Ada library

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> In the last version I saw the tag was hidden. So using inheritance for
> extension is closed.

That is indeed that case.  The containers do not support type extension.
(Note that the containers are tagged because that's the only way to get
controlledness.)

> The main component currently used are bounded queues and all Ada.Components
> I know of are unbounded. Yes you can use a Vector to create a Queue. And
> any unbouded type can be make bounded. However with an hidden tag its extra
> effort.

We added lists, which support queue-type functionality.

We are currently discussing whether deletion at the front end of a
vector should be O(1) (instead of just O(n) or O(log n)), which would
influence whether a vector could be used as a queue, too.

These are both unbounded forms, however, but that will still work for
your application, won't it?

The latest version of Charles has bounded lists (they aren't controlled
or tagged, either), so you could always use those if you really want a
bounded form.

Why do you need type extension?  


> I am there too shouting "indefinite elements" all the time.

We added indefinite forms to AI-302.  I'll add them to Charles as soon
as we finish the latest draft AI.

-Matt

Re: Unified Ada library

[Ludovic Brenta]

Matthew Heaney writes:
> Charles has direct support for multimaps.  AI-302 does not.  To get
> a multimap-like container from AI-302 components, you'll have to use
> a (hashed) map with a vector or list as its element.

Matthew,  I must say I appreciate all the work you've done so far.

Do you anticipate that, in the long run, Charles will be split into
two parts, AI-302 and complementary containers and algorithms built on
top of AI-302?  Or that Charles will remain, essentially unchanged, as
an alternative to AI-302?

-- 
Ludovic Brenta.

Re: Unified Ada library

[Craig Carey]

On Fri, 16 Apr 2004 00:22:34 GMT, Jeffrey Carter <spam@spam.com> wrote:

>Randy Brukardt wrote:
>
>> For what it's worth, you don't have to shout anymore. The ARG spent 6 hours
>> on containers in Phoenix, and one of the many decisions was to include the
>> indefinite versions of the containers. Indeed, pretty much everything that
>> was discussed on Ada-Comment was added (Lists, set operations, and more).
>> 
>> Matt, Tucker, and I are working on a new draft with all of the changes
>> included; hopefully that will be done this week. (You can see the discussion
>> in the ARG minutes; the draft for the Phoenix meeting is up on the web
>> site.)
>
>I'm in the Phoenix area. I wish I'd known. Unlike Heaney, I can't afford 
>to fly all over the world promoting my view of Ada. Are these things 
>open to the public?
>

No need to fly to a meeting?. It is could be unsafe to be obscure.

>Regarding the minutes, I mostly like what I see ...


So it seems that Mr Brukhardt suggests that ARG might let that
C++ data structures features into Ada 95.

I hope the Mr Taft and Mr Brukhardt get the ARG to stop putting time
into the consideration of all of the data structures packages and
instead there can be a website. I tried to argue to Mr M Heaney that
a very different package results if speed is an aim and ideology is
not allowed to be used. Ideology can lead to hint of an Algol 68
style where there is some fullness of cases.

Only 6 hours spent by the ARG. No problem since they could put an
unlimited amount of time into it and still pass something.

It is a plan to stabilize on something suboptimal that should not be
passed, easily forever. So maybe ACT would vote yes. That company
promoted to the Ada-Comment mailing list their GNAT.Sockets package.

Possibly a better alternative is a single zip file at some website
like http://www.adaic.org/ website.

If the aim was to bring C++ into Ada 95, there are basic syntax
features in Ada that are missing and that would hinder the porting
of C++ code to Ada 95.

How did Ada 95 get the super slow byte by byte theme that is in
its new "streams" features ?.

Suppose the reality for the ARG is like this: comp.lang.ada figures
it out early and withdraws and the ARG gets a small number of
comments. Maybe 4 packages might get mixed.

I can liken ARG's approving of C++-isms with how the chess scene.
There seems to be much over 100 chess programs and the Arena program
allows the quality of chess programs to be compared.

Arena:  http://www.playwitharena.com/   Just about all are losers

Currently  C++ programmers can fault Ada for
failing to resolve the overloading of package names, with the names
of subtypes inside the package. I.e., porting C++ classes to Ada
could do with improving. A check is needed to estimate if Ada is
getting C++-ised or whether the concrete-us-first bugs is becoming
an issue with the community's leaders.

With Mr Taft there, and GNAT's stance on getting stabilized over
backwards compatible designs, I lack confidence that ARG will do
nothing in this which seems that safest course and lacking any
associated problem.

It seems that the whole matter can be resolved without even reading
most of the documents. Perhaps Mr Heaney's much checked code
real-Ada code (to the casual eye) could be online at adaworld.com
instead of getting approved.

This comment is rough and I was not reading the e-mails at the
Ada-Comment mailing list. 

I am not against Mr Heany's code any more than inferior code.
Possibly this e-mail gets missed.



--  Craig carey

Re: Unified Ada library

[Björn Persson]

Matthew Heaney wrote:

> Björn Persson <spam-away@nowhere.nil> writes:
> 
> 
>>Actually, I need a kind of ordered many-to-one mapping. I need to map
>>several keys to the same value (the same object, not identical
>>values), and iterate over the values (not the keys) in the same order
>>that they were added in. I guess that's too specialized for
>>Ada.Containers. I didn't find that in Booch either, so right now I
>>have my own ad-hoc solution for that, built around a dynamic vector
>>from Charles.
> 
> 
> It sounds like you need a multimap, with an element that's a pointer to
> the object shared among equal keys.

I got the impression that a multimap is multi because it allows multiple 
identical keys with different values (or put another way, one key may be 
mapped to several elements). That's not what I need.

Reading charles-multimaps-sorted-unbounded.adb I don't see a way to add 
a new key and connect it to an element that is already in the container.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library

[Georg Bauhaus]

Matthew Heaney <matthewjheaney@earthlink.net> wrote:
 
: In any event you'd have to
: write the algorithm above like this:
: 
:   P := Find (List, E);
:   J := First (List);
:   K := Last (List);
: 
:   while J /= P and then K /= P loop
:      ...
:      Next (J);
:      Previous (K);
:   end;
: 
: (At least I think this is what you meant.)

Yes, thanks. And maybe the three cursors in the example shed some light 
on some other things from the minutes text that might be
related to each other, and led me to some speculations:

- "there are not many cursor objects in a program"
  vs.
- "Should we have set operations for Set?"

I think providing a fixed set of operations is more typical of
a Booch components approach rather than of a Charles components
approach, where the set operations would be generically
expressed using Set Iterators in e.g. generic union and intersection
algorithms? (AI302.Containers.Ordered_Sets uses instances of
Charles generic algorithms, AFAICS.)

If instead the containers provide the operations on their elements,
i.e. if the operations will not be provided by generic algorithms,
then the two quotes above fit together, in my head at least.


- "subranges are unlikely"

In an ordered data structure it is easy to find a range
of interesting items, to be passed to some algorithm.
For example, all persons named "Miller" from a telephone directory,
in order.
With the AI 302 dicussion in mind I think this is easily achieved with
either one of

1) one Cursor. It starts at the first occurence of "Miller"
   and ends at the last occurence of "Miller" (not Exists(it))

2) two Iterators. one pointing to the first Miller, the second
   pointing to the last (or beyond, as in Eiffel ITERATORs, and C++ STL)

If (1) is chosen, the Cursor object passed must carry and hide
the information that is made explicit in (2), right?

Another example is statistics. All persons with income <= 1_000,
with income between 1_001 and 2_000, and so on, for each calculate
some interesting numbers, collected from subject data in each group.
The calculations are the same for each group, the ranges are not,
the iterators are not, but both are frequently occuring.


My 2c,
Georg

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:
> My reason to choose an indefinite type in this case has been that
> I wan't a construtor to initialise the components of Link
> objects. Default values won't do because they are not known
> until runtime. How to express this requirement so that the
> compiler will check?

If I understand correctly, you want all objects of the type to be 
initialized when created using values not available until runtime. You 
think you need an indefinite type and a subprogram to do this, but it 
seems to me simply specifying the discriminants without defaults has the 
same effect. Consider:

package Discriminant_Test is
    type Link (D : access Integer) is tagged limited null record;

    V : Link;
end Discriminant_Test;

GNAT 3.15p reports an error with the declaration of V: "unconstrained 
subtype not allowed (need initialization)". So simply declaring

type Link (Source, Destination: access Node) is tagged limited private;

requires that the client provide the necessary initialization 
information when he declares an object of the type.

-- 
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29

Re: Unified Ada library

[Matthew Heaney]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Matthew Heaney writes:
> > Charles has direct support for multimaps.  AI-302 does not.  To get
> > a multimap-like container from AI-302 components, you'll have to use
> > a (hashed) map with a vector or list as its element.
> 
> Matthew,  I must say I appreciate all the work you've done so far.

Thanks.  There's still a lot of work left to do, however.


> Do you anticipate that, in the long run, Charles will be split into
> two parts, AI-302 and complementary containers and algorithms built on
> top of AI-302?  Or that Charles will remain, essentially unchanged, as
> an alternative to AI-302?

Someone else was asking about that.  The answer is, I don't know yet.

There are two paths we could follow:

(1) Keep Charles as is (but add the rest of the algorithms, etc), and
    create a separate library a la the C++ boost library to test out
    AI-302 style containers for possible inclusion in a secondary Ada
    library standard.

(2) Morph Charles into something that's more in the style of AI-302.

Right now, I'm leaning towards (1).  The thing I like about Charles is
that it's a relatively pure port of the STL to Ada95.  There are C++
developers who think that the STL could only have been written in C++,
and Charles is my argument that that claim is false.

Most Ada developers who have a familiarity with the STL immediately
understand how Charles works, which supports my argument.

Both Charles and the AI-302 reference implementation are available at
the tigris page:

<http://charles.tigris.org/>

There's still a large chunk of Charles that's still at my Earthlink
homepage, and I'm currently working to move the rest of it over.  I want
to get that all taken care of prior to my Charles tutorial at Ada-Europe
in June.

-Matt

Re: Unified Ada library

[Hyman Rosen]

Matthew Heaney wrote:
> Right now, I'm leaning towards (1).  The thing I like about Charles is
> that it's a relatively pure port of the STL to Ada95.  There are C++
> developers who think that the STL could only have been written in C++,
> and Charles is my argument that that claim is false.

Bravo. I hope you keep going with this. You will have to watch out for the
Ada people who hate and fear C++ and will seek to turn this library into
something that is more "like Ada" in their perception, and will thereby kill
it.

Re: Unified Ada library

[Matthew Heaney]

Bj�rn Persson <spam-away@nowhere.nil> writes:

> Matthew Heaney wrote:
> > It sounds like you need a multimap, with an element that's a pointer to
> > the object shared among equal keys.
> 
> I got the impression that a multimap is multi because it allows multiple
> identical keys with different values (or put another way, one key may be
> mapped to several elements). That's not what I need.

Yes, a multimap allows multiple key/element pairs to have identical key
values.


> Reading charles-multimaps-sorted-unbounded.adb I don't see a way to add
> a new key and connect it to an element that is already in the container.

The way to do that is to let the element type be a pointer:

  type Data_Type is ...;
  type Data_Access is access all Data_Type;

  function "<" (L, R : Data_Access) return Boolean is
  begin
    return L.all < R.all;
  end;

  package Data_Multimaps is
    new Charles.Multimaps.Sorted.Unbounded
     (Key_Type,
      Data_Access,  --NOTE: access type
      "<",
      "=");         --at your option

There are now a few ways you can go.  The first is to attempt to Find that key:

  M : Data_Multimaps.Container_Type;
  ...
  I : Data_Multimaps.Iterator_Type := Find (M, K);  

begin

  if I = Back (M) then -- not found
  
     Insert
       (Container => M,
        Key       => K,
        New_Item  => new Data'(...),
        Iterator  => I);

   else  -- already in map

     Insert
       (Container => M,
        Position  => I,  -- use hint
        Key       => K,
        New_Item  => Element (I),  -- share data
        Iterator  => I);  -- or whatever

   end if;

end;


If the key isn't already in the map, then we allocate a new data element
and perform an actual insertion.  If the key is in the map, then the
iterator returned by Find gives us the element value we want to share,
and so we insert a new key/element pair with that element value.

Note the I used the insert-with-hint form in the second branch.  This
turns the tree traversal into O(1) if the hint really turns out to be a
neighbor, which is the case here since Find returned a matching key.

However, you might have noticed that in the first branch, the insert
(sans hint) must essentially duplicate the work of Find, in order to
find the correct insertion position.  There is no need for this.

What we do is use Lower_Bound instead of Find.  Lower_Bound searches for
the smallest key not less than the key, which is just fancy way to say:

   Key <= Lower_Bound (M, Key)

The issue with Find is that it returns the Back sentinel if the search
fails, but there's nothing we can really do what that value.
Lower_Bound is better because it either returns the key if it's already
in the map, or its successor if it were in the map.  We can rewrite the
example above to use Lower_Bound instead of Find, like this:


  I : Data_Multimaps.Iterator_Type := Lower_Bound (M, K);  

begin

  if Is_Less_Key (K, I) then  -- did not match
  
     Insert
       (Container => M,
        Position  => I,  -- use hint
        Key       => K,
        New_Item  => new Data'(...),
        Iterator  => I);

   else  -- already in map

     Insert
       (Container => M,
        Position  => I,  -- use hint
        Key       => K,
        New_Item  => Element (I),  -- share data
        Iterator  => I);  -- or whatever

   end if;

end;


Now we can insert-with-hint in both branches.

If this does not meet your needs, let me know and we'll figure something
out.

Regards,
Matt

Re: Unified Ada library

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Yes, thanks. And maybe the three cursors in the example shed some
> light on some other things from the minutes text that might be related
> to each other, and led me to some speculations:
> 
> - "there are not many cursor objects in a program"
>   vs.
> - "Should we have set operations for Set?"

The operations Intersection, Union, Difference, and Symmetric_Difference
were added to the ordered set container.


> I think providing a fixed set of operations is more typical of
> a Booch components approach rather than of a Charles components
> approach, where the set operations would be generically
> expressed using Set Iterators in e.g. generic union and intersection
> algorithms? (AI302.Containers.Ordered_Sets uses instances of
> Charles generic algorithms, AFAICS.)

Yes, the reason they're not in the Charles sets is because you get that
functionality by instantiating the generic algorithms.

However, there was interest in having union, etc, for the ordered sets
in AI-302, so we added them to the ordered set container directly.

Yes, the AI-302 reference implementation uses the Charles algorithms to
implement those operations.


> If instead the containers provide the operations on their elements,
> i.e. if the operations will not be provided by generic algorithms,
> then the two quotes above fit together, in my head at least.

I don't think the quotes are related.  We added the operations to the
ordered set because they were desired, and because there was no generic
algorithm alternative.


> - "subranges are unlikely"
> 
> In an ordered data structure it is easy to find a range
> of interesting items, to be passed to some algorithm.
> For example, all persons named "Miller" from a telephone directory,
> in order.

There are no multi-map or multi-set containers in AI-302.  In this case,
you probably want a map, with a vector or list as the element.


> With the AI 302 dicussion in mind I think this is easily achieved with
> either one of
> 
> 1) one Cursor. It starts at the first occurence of "Miller"
>    and ends at the last occurence of "Miller" (not Exists(it))

There are no multimaps in AI-302.


> 2) two Iterators. one pointing to the first Miller, the second
>    pointing to the last (or beyond, as in Eiffel ITERATORs, and C++ STL)

If you had a multimap, that's how you'd do it.  In the case of Charles
(and STL), you'd use Lower_Bound and Upper_Bound to demarcate the range
of equal keys, and then iterate over that range.

But AI-302 doesn't have a multimap.


> If (1) is chosen, the Cursor object passed must carry and hide
> the information that is made explicit in (2), right?

In AI-302, you need to use a map, with a vector or list as the element.
You only need one cursor, to designate the key/element pair whose key is
"Miller".


> Another example is statistics. All persons with income <= 1_000, with
> income between 1_001 and 2_000, and so on, for each calculate some
> interesting numbers, collected from subject data in each group.  The
> calculations are the same for each group, the ranges are not, the
> iterators are not, but both are frequently occuring.

This would be a good use for the Lower_Bound and Upper_Bound operations
of a sorted set (Charles only).

Unfortunately, the ARG removed the Lower_Bound and Upper_Bound
operations from the ordered set in AI-302, so I'd have to think about
how to solve your problem.

-Matt

Re: Unified Ada library

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> writes:

> Matthew Heaney wrote:
> > Right now, I'm leaning towards (1).  The thing I like about Charles is
> > that it's a relatively pure port of the STL to Ada95.  There are C++
> > developers who think that the STL could only have been written in C++,
> > and Charles is my argument that that claim is false.
> 
> Bravo. I hope you keep going with this. You will have to watch out for
> the Ada people who hate and fear C++ and will seek to turn this
> library into something that is more "like Ada" in their perception,
> and will thereby kill it.


I like C++, and I like the STL.  I don't know what engenders such
vitriol against a language.

(I should take this opportunity to remind developers on this list the
C++ is not C.  C++ fixed many errors in C by adding better static type
checking, type-safe linkage, user-defined types, etc).

-Matt

Re: Unified Ada library

[Martin Krischik]

Matthew Heaney wrote:

> We are currently discussing whether deletion at the front end of a
> vector should be O(1) (instead of just O(n) or O(log n)), which would
> influence whether a vector could be used as a queue, too.

For a bounded queue this is not needed since a bounded queue could use the
ring approach. With that approach no elements a removed - only replaced.
 
> These are both unbounded forms, however, but that will still work for
> your application, won't it?

Again, with a ring approach this is not needed since the ai containers can
be preallocated. You just preallocate the vector to n elements are and then
round robin those elements to form the queue.

This is the way th booch components do it.

My main point still is: with an open tag this could be done more elegant.

> The latest version of Charles has bounded lists (they aren't controlled
> or tagged, either), so you could always use those if you really want a
> bounded form.
> 
> Why do you need type extension?

type Queue
is new 
   Vector
with record
   Size : Index_Type;
end record;

function Length (Container : Vector)
return Size_Type
renames Ada.Containers.Vectors.Length;

seems to me more natural (and shorter) then

package Vectors
is new Ada.Containers.Vectors (
    Index_Type => Index_Type ;
    Element_Type => Index_Type ;
    "=" => "=" )ￜ; 

type Queue
is tagged record
   Data :  Vectors.Vector;
   Size : Index_Type;
end record;

function Length (Container : Queue)
return Size_Type;

pragma Inline (Lenght);

function Length (Container : Queue)
    return Size_Type
is
begin
    Ada.Containers.Vectors.Length (Queue.Data);
end Length;

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
: GNAT 3.15p reports an error with the declaration of V: "unconstrained 
: subtype not allowed (need initialization)". So simply declaring
: 
: type Link (Source, Destination: access Node) is tagged limited private;
: 
: requires that the client provide the necessary initialization 
: information when he declares an object of the type.

Yes, that would work if there weren't requirements for the other
private record components that can't be fulfilled using defaults.
Like

   type Link (Source, Destination: access Node) is tagged limited
      record
         part: Some_Type := ???;   -- no reasonable default
      end record;

I think I'll have to live with the situation or try to find
some other mechanism.


Thanks,
Georg

Re: Unified Ada library

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: Matthew Heaney wrote:
 
:> Why do you need type extension?
: 
: type Queue
: is new 
:   Vector
: with record
:   Size : Index_Type;
: end record;

Though you would have to hide some Vector operations in order
to guarantee integrity of the queue (random access, Prepend, etc.)

I have had a need for a queue too, so I made the following, to
which I have added your Size component:

with AI302.Containers.Vectors;

generic
   type Element is private;

package Queues is

   type Queue(size: Natural) is private;

   procedure enqueue(q: in out Queue; e: Element);

   procedure dequeue(q: in out Queue; e: out Element);

   function is_empty(q: Queue) return Boolean;

private
   package Implementation is new AI302.Containers.Vectors
     (Index_Type => Natural, Element_Type => Element);


   type Queue(size: Natural) is new implementation.Vector;

end Queues;



-- Georg

Re: Unified Ada library

[Jano]

Matthew Heaney dice...
> Jano <nono@unizar.es> wrote in message news:<MPG.1aea1f788efb778c9896e6@news.able.es>...
> > Randy Brukardt dice...
> > > 
> > > If you're going to switch container libraries, I'd strongly suggest
> > > considering using Ada.Containers, the proposed container library for Ada
> > > 200Y. 
> > 
> > Link, please?
> 
> <http://charles.tigris.org/source/browse/charles/src/ai302/>

Thanks!

Re: Unified Ada library

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Matthew Heaney wrote:
:> Right now, I'm leaning towards (1).  The thing I like about Charles is
:> that it's a relatively pure port of the STL to Ada95.  There are C++
:> developers who think that the STL could only have been written in C++,
:> and Charles is my argument that that claim is false.
: 
: Bravo. I hope you keep going with this. You will have to watch out for the
: Ada people who hate and fear C++ and will seek to turn this library into
: something that is more "like Ada" in their perception, and will thereby kill
: it.

Could you comment on the importance of iterators and generic
algorithms in the template libraries?


I just stumbled across this in Stroustrup's Language book (sections
16.2.1-3):

"The standard library containers and iterators (often called
the STL framework ..) can be understood as an approach to gain
the best of the two traditional models described previously [*].
That wasn't the way the STL was designed, though.  The STL was the
result of a single-minded search for uncompromisingly efficient
and generic algorithms.

"The aim of efficiency rules out hard-to-inline virtual functions
....  Therefore, we cannot present a standard interface to containers
or a standard iterator interface as an abstract class. Instead,
each kind of container supports a standard set of basic operations.
... Operations that cannot be efficiently implemented for all
containers are not included in the set of common operations.
 ... Each kind of container provides its own iterators that
support a standard set of iterator operations.

"The standard containers are not derived from a common base. Instead,
every container implements all of the standard container interface.
[dito for iterators].  No ... run-time type checking is involved.

 [*] Specialized Containers and Iterators, generics with type parameters
together with Iterator objects for the containers,
versus Based Containers, of a common base type, and with fat interfaces.

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> Yes, that would work if there weren't requirements for the other
> private record components that can't be fulfilled using defaults.
> Like
> 
>    type Link (Source, Destination: access Node) is tagged limited
>       record
>          part: Some_Type := ???;   -- no reasonable default
>       end record;

As I recall, your initialization function had the form

function Make (Source, Destination : access Node) return Link;

Where would these additional values come from in this form of the 
solution? Clearly there is some way to supply them. You can achieve the 
same effect with

type Link (...) is tagged limited record
    Part : Some_Type := Some_Function;
end record;

Some_Function can have the same access to the same state information at 
runtime that Make could have.

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> I have had a need for a queue too, so I made the following, to
> which I have added your Size component:

There are plenty of queues in the PragmAda Reusable Components, and 
they're likely to be more efficiently implemented than something based 
on the reference implementation of the Ada.Containers unbounded array 
component, Vector.

http://home.earthlink.net/~jrcarter010/pragmarc.htm

-- 
Jeff Carter
"Help! Help! I'm being repressed!"
Monty Python & the Holy Grail
67

Re: Unified Ada library

[Matthew Heaney]

Jeffrey Carter <spam@spam.com> writes:

> There are plenty of queues in the PragmAda Reusable Components, and
> they're likely to be more efficiently implemented than something based
> on the reference implementation of the Ada.Containers unbounded array
> component, Vector.

Jeff is correct that the current version of the AI-302 vector isn't
intended for use as a queue -- that's what the list is for.

(We got rid of aliasing of vector components, so that will allow
deletion from the front of a vector to have O(1) time complexity.  But
that's not done yet, pending resolution of some technical issues in the
latest draft AI.)

-Matt

Re: Unified Ada library

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : Matthew Heaney wrote:
>  
> :> Why do you need type extension?
> : 
> : type Queue
> : is new
> :   Vector
> : with record
> :   Size : Index_Type;
> : end record;

> Though you would have to hide some Vector operations in order
> to guarantee integrity of the queue (random access, Prepend, etc.)

Yes, and as a OOD I know it is not best example. The classic question - "a
queue is a vector" versus "a queue has vector" - is ticky to answer here.
 
> I have had a need for a queue too, so I made the following, to
> which I have added your Size component:

> with AI302.Containers.Vectors;
> 
> generic
>    type Element is private;
> 
> package Queues is

Shure, I would do the same if I wanted to use Ada.Containers. How about:

package Ada.Containers.Queues 

or looking over the fence to the C++ comunity:

package Boost.Containers.Queues

>    type Queue(size: Natural) is private;
> 
>    procedure enqueue(q: in out Queue; e: Element);
> 
>    procedure dequeue(q: in out Queue; e: out Element);
> 
>    function is_empty(q: Queue) return Boolean;

function Is_Full (q: Queue) return Boolean; 

> private
>    package Implementation is new AI302.Containers.Vectors
>      (Index_Type => Natural, Element_Type => Element);
> 
> 
>    type Queue(size: Natural) is new implementation.Vector;
> 
> end Queues;

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Unified Ada library

[Hyman Rosen]

Georg Bauhaus wrote:
> Could you comment on the importance of iterators and generic
> algorithms in the template libraries?

You can write your algorithms for the most part as if you were
using pointers to iterate over arrays. Because no virtual
operations are involved, and because C++ compilers have been
taught that inlining template code is vital, the resulting
compiled code becomes very efficient. If the pointer-like code
attempts an operation that would be inefficent for some given
container (such as trying to subtract two iterators when they
refer to a linked list instead of an array), the code won't
compile because the operation isn't defined.

The idea was to have containers and algorithms that did not force
code to pay runtime abstraction penalties over use of plain arrays.
It was vital that code which used std::vector should be as efficient
as plain arrays for the things that plain arrays could do, otherwise
the community would have rejected the standard containers.

Not only that, having the algorithms look like array/pointer operations
allows them to be used on arrays as well as containers, since pointers
are iterators, and it comforts C programmers who can write code in the
style they are used to.

Re: Unified Ada library

[Björn Persson]

Matthew Heaney wrote:
[a tutorial about multimaps]

That was an interesting lesson, Matt. I like the insert-with-hint 
feature. Unfortunately you still haven't understood what I want to do.

Look at the example I posted (2004-04-09 23:14; message ID 
<gnEdc.89265$dP1.265199@newsc.telia.net>; the first post with only "Re: 
Unified Ada library" in the title).

The key type is an enumeration defined by the program that uses my 
package - the type Parameter in the example. Each key will occur in the 
map exactly once. The elements are records with all sorts of information 
about the parameters. To provide ease of use to the end user, parameters 
may have synonyms. "Check" and "v" might both be synonyms for "verify" 
for example. Boolean parameters may also have antonyms, like "no_milk" 
in the example. All synonyms and antonyms must be mapped to the same 
info record.

So far it looks like I could just use an array of pointers to info 
records: "Info : array(Parameter) of Info_Pointer". But then there's the 
help function. When "--help" is found on the command line, descriptions 
of all the parameters should be printed. I can't print the same 
description for each of the synonyms as if they were separate 
parameters. The description should be printed once with the synonyms 
listed. Therefore I need to iterate over the info records and visit each 
record only once.

Same thing with omitted parameters. When the whole command line has been 
read, I iterate over the info records and check for parameters that 
weren't found on the command line. If they're optional I assign default 
values; otherwise I print error messages. While it wouldn't hurt to 
assign a default value multiple times the error message should only be 
printed once.

I solved this by storing the info records in a vector and keeping an 
array of indices:

    subtype Info_Index is Positive
      range 1 .. Parameter'pos(Parameter'last) -
                 Parameter'pos(Parameter'first) + 1;
    package Info_Vectors is
      new Charles.Vectors.Unbounded(Info_Index, Parameter_Info);
    Info : aliased Info_Vectors.Container_Type;
    Info_Number : array(Parameter) of Info_Index;

So I have a solution, though maybe not the most elegant one. I just 
mentioned it because if I had found a library that provided a 
many-to-one map and used that I wouln't have wanted to throw that out 
and use only Ada.Containers.

-- 
Björn Persson

jor ers @sv ge.
b n_p son eri nu

Re: Unified Ada library

[Warren W. Gay VE3WWG]

Matthew Heaney wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
>>I responded to this issue in a prior post today.  In short, I need
>>"tree sharing" and a "tree API" to work with a parse tree (one
>>example). If you want to fully understand why, use
>>BC.Containers.Tree.Multiway, and think about how you would use this
>>with ayacc.
> 
> I see what you're getting at, but the current AI is very modest, and
> therefore doesn't support recursive data structures.

That is understood: I wasn't trying to be critical.

> The tree container is a good idea, though, and we should keep it in mind
> for inclusion in a secondary standard.
> 
> -Matt

One other thing (if it is not too late), is to perhaps include
something like BC.Support.Smart_Pointers. This should be a fairly
trivial library addition code wise (though possibly not standards
wise). It would save people from having to (re)code this
themselves, every time it is needed. Just another $0.02 worth ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Unified Ada library

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:
 
: type Link (...) is tagged limited record
:    Part : Some_Type := Some_Function;
: end record;
: 
: Some_Function can have the same access to the same state information at 
: runtime that Make could have.

(Lifting my forehead from the desk. "Some_Function" has removed
another prism from my glasses.) Thanks a lot, this brings me 
close to a very nice solution.


Georg

Re: Unified Ada library

[Lutz Donnerhacke]

* Georg Bauhaus wrote:
> Jeffrey Carter <spam@spam.com> wrote:
>: type Link (...) is tagged limited record
>:    Part : Some_Type := Some_Function;
>: end record;
>>
>> Some_Function can have the same access to the same state information at
>> runtime that Make could have.
>
> (Lifting my forehead from the desk. "Some_Function" has removed another
> prism from my glasses.) Thanks a lot, this brings me close to a very nice
> solution.

  task body xxx is
     y : Link(...);
  begin
     ...

results in TASKING_ERROR while elaboration a new task. Removing the
initializing part of the type works. (gcc version 3.3.2)

So be careful.

Re: Unified Ada library

[Georg Bauhaus]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:
: * Georg Bauhaus wrote:
:> Jeffrey Carter <spam@spam.com> wrote:
:>: type Link (...) is tagged limited record
:>:    Part : Some_Type := Some_Function;
:>: end record;

 
:  task body xxx is
:     y : Link(...);
:  begin
:     ...
 
: results in TASKING_ERROR while elaboration a new task. Removing the
: initializing part of the type works. (gcc version 3.3.2)

With some dummy code, this appears not to be the case with a more
recent GCC, and with ObjectAda 7.2.2. Is this just a property of
GCC 3.3.2 and/or some OS?

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> Lutz Donnerhacke <lutz@iks-jena.de> wrote:
> : * Georg Bauhaus wrote:
> :> Jeffrey Carter <spam@spam.com> wrote:
> :>: type Link (...) is tagged limited record
> :>:    Part : Some_Type := Some_Function;
> :>: end record;
> 
>  
> :  task body xxx is
> :     y : Link(...);
> :  begin
> :     ...
>  
> : results in TASKING_ERROR while elaboration a new task. Removing the
> : initializing part of the type works. (gcc version 3.3.2)
> 
> With some dummy code, this appears not to be the case with a more
> recent GCC, and with ObjectAda 7.2.2. Is this just a property of
> GCC 3.3.2 and/or some OS?

This looks like a compiler error. Of course, if Some_Function is not 
task safe, such a declaration may produce unintended results.

-- 
Jeff Carter
"There's no messiah here. There's a mess all right, but no messiah."
Monty Python's Life of Brian
84

Re: Unified Ada library

[Jeffrey Carter]

Georg Bauhaus wrote:

> (Lifting my forehead from the desk. "Some_Function" has removed
> another prism from my glasses.) Thanks a lot, this brings me 
> close to a very nice solution.

It's called "Ada.Finalization" because Ada 83 already had perfectly good 
mechanisms for initialization.

-- 
Jeff Carter
"There's no messiah here. There's a mess all right, but no messiah."
Monty Python's Life of Brian
84

Re: Unified Ada library

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
 
Thanks!

: You can write your algorithms for the most part as if you were
: using pointers to iterate over arrays.

Hm. Given Ada arrays, I'm wondering whether there should be
more general support for slicing, not just Splice for Lists.
Or whether sclices (for sorted containers?) should be handled by a

  procedure Generic_Replace_Slice(<curors...>).

Just a thought.

Re: Unified Ada library

[Dmitry A. Kazakov]

On Thu, 22 Apr 2004 12:33:35 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Hyman Rosen <hyrosen@mail.com> wrote:
> 
>: You can write your algorithms for the most part as if you were
>: using pointers to iterate over arrays.
>
>Hm. Given Ada arrays, I'm wondering whether there should be
>more general support for slicing, not just Splice for Lists.
>Or whether sclices (for sorted containers?) should be handled by a
>
>  procedure Generic_Replace_Slice(<curors...>).
>
>Just a thought.

If you have an index type (its value is a cursor), then sets of index
types are things which define slices (i.e. range) and submatrices
(dense or not) etc. One can made it as complex as one might wish.
Important for generic programming (in any form) to have an ability to
get the index type(s) of a container object.

As for Generic_Replace_Slice, if you have that sets of indices, then
you can built anonymous array subtypes upon them. So replace could
look as:

   A (<submartix>) := B;

Just a thought (:-))

--
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Unified Ada library

[Craig Carey]

On Sun, 18 Apr 2004 04:19:56 GMT, Matthew Heaney  wrote:
>Hyman Rosen <***n@mail.com> writes:
>> 
>> Bravo. I hope you keep going with this. You will have to watch out for

.                we/they

>> the Ada people who hate and fear C++ and will seek to turn this
>> library into something that is more "like Ada" in their perception,
>> and will thereby kill it.

If I got it right, the plan is to introduce "do it one by one" idealisms
and then as expected by at least the C++ folk, it just lacks the 
unpackageable complexity that would be appropriate.

Mr Heaney's (and Mr Carter's) code could go onto the Internet.

Even books can say that C++ copy (and along with perhaps over 40 other
competing packages from Eiffel and other languages with a following)
are now almost the authoritative version of that code that you would not
want to leave unmodified for more than avg. 0.5 weeks if actually used.

So apparently Ada 95 (Pascal (of IBM), etc.) is going to help beginners
get the 'ARG approved' Ada. Why doesn't the ARG mention them more
clearly?. C++ization and the rise of the changing Charles package is
not for experts.
 
Ada textbooks could be free, so having a purpose of officializing
the containerized readily unused clumpons that run slower and lack
debugging checks and tweaks, and are built over the idea of ignoring
the code's design, and doing things one by one, and then having the
code run too slow, is really something that even these unmentioned
students might not want to just have no opinion on.

Mr Rosen suggests that Mr Heaney should keep going.

Can someone identify a group of C++ programmers who articulately
and reasonably have a case for the bitsy-clumponizations of the
Ada Annotated Reference Manual ?. Are we missing their names too,
and also: in which year of this century, do the ARG's students
exist (the ones with a latent need for the fixes).

Is this about the 'prestige' of solidifying the Reference Manual.
I am against that.

...
>(I should take this opportunity to remind developers on this list the
>C++ is not C.  C++ fixed many errors in C by adding better static type
>checking, type-safe linkage, user-defined types, etc).
>
>-Matt

Re: Unified Ada library

[Hyman Rosen]

Craig Carey wrote:
... < a rant that looks like it went through a Zippy the Pinhead processor > ...

You might want to control your righteous indignation just enough so that
your English is more coherent. (I charitably suppose that it's not your
native language.)

 From what I can make out of your statement, the reason we process aggregates
one-by-one is, just like the reason for Time given by Buckaroo Banzai, so that
everything doesn't happen at once.

Re: Unified Ada library

[Georg Bauhaus]

Craig Carey <research@ijs.co.nz> wrote:
: 
: If I got it right, the plan is to introduce "do it one by one" idealisms
: and then as expected by at least the C++ folk, it just lacks the 
: unpackageable complexity that would be appropriate.

Barring generic algorithms?

Re: Unified Ada library

[Matthew Heaney]

Craig Carey <research@ijs.co.nz> writes:

> So apparently Ada 95 (Pascal (of IBM), etc.) is going to help
> beginners get the 'ARG approved' Ada. Why doesn't the ARG mention them
> more clearly?. C++ization and the rise of the changing Charles package
> is not for experts.

Work on next release of the AI-302 draft is progressing, and it should
be released sometime soon -- probably this week.

Once the draft of the AI has been released, I plan on synchronizing the
AI-302 reference implementation to the text of the AI, and on migrating
the remaining Charles packages from my home page to the tigris site.

-Matt

Re: Unified Ada library

[Craig Carey]

Does Tigris allow Subversion to used with some success ?.
   http://charles.tigris.org/
Maybe Tigris could be used for other Ada 95 projects. Perhaps.
Do they provide use of Subversion to the Charles project ?.


On Wed, 28 Apr 2004 02:04:38 GMT, Matthew Heaney wrote:
...
>Work on next release of the AI-302 draft is progressing, and it should
>be released sometime soon -- probably this week.
>
>Once the draft of the AI has been released, I plan on synchronizing the
>AI-302 reference implementation to the text of the AI, and on migrating
>the remaining Charles packages from my home page to the tigris site.
>
>-Matt

I am now unclear on AI-302. Pehaps it could be OK for the RM. But it
should allow the hybrid algorithms speeding up the Ada containers
library, to be optimized.

Here is a sample article [referring to the 1994 C++ STL]. It shows that
a simple design can be slow. The Ada package spec ought allow the
tweaking parameters to be specified.

---
| B+ Retake: Sustaining High Volume Inserts into Large Data Pages (2001)
| Kurt Deschler, Elke A. Rundensteiner. International Workshop on Data Warehousing and OLAP
 ...
| To compare memory performance of the B+ and RB+ trees, we have
| implemented both structures in C++ using the Standard Template Library
| (STL) [ http://www.sgi.com/tech/stl/ ]. ... experiments prove that the
| RB+ tree can improve insert times by 3,000% when used with large data
| pages. //... [but there are] increased I/O costs ...

   http://citeseer.ist.psu.edu/deschler01retake.html

I'd prefer AI-302 to implement the most complex data structure (some
improved hybrid B-Tree algorithm) rather than anything as simple as the
linked list idea that apparently was being discussed.

---

AI-302:

| From: Robert A. Duff
| Sent: Monday, February 9, 2004  4:27 PM
|
| ... there are discussions going on in Ada-Comment, and also on arg.
| People are raising some of the same points on both.
| ... some key ARG members are not currently listening to Ada-Comment,
| and many Ada-Comment folks are not seeing the ARG mailing list.

 From:   http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-30302.TXT

There is a lengthy report on the AI-302 discussions at Phoenix in 5-7 
March 2004, here:
   http://www.ada-auth.org/arg-minutes.html



- Craig Carey
function S(T : out L =: <>) is ...; --  Minor Issue # AC-00092
--  Default out mode parameters

Re: Unified Ada library

[Matthew Heaney]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
> > Another example is statistics. All persons with income <= 1_000,
> > with income between 1_001 and 2_000, and so on, for each calculate
> > some interesting numbers, collected from subject data in each group.
> > The calculations are the same for each group, the ranges are not,
> > the iterators are not, but both are frequently occuring.
> 
> This would be a good use for the Lower_Bound and Upper_Bound
> operations of a sorted set (Charles only).
> 
> Unfortunately, the ARG removed the Lower_Bound and Upper_Bound
> operations from the ordered set in AI-302, so I'd have to think about
> how to solve your problem.

The functions Ceiling and Floor were officially added back to the
container library API during the ARG meeting Palma de Mallorca.

I have updated the reference implementation to include most of the
changes requested at the Palma meeting:

<http://charles.tigris.org/source/browse/charles/src/ai302/>

To implement the algorithm you describe above, you could do something
like this:

procedure Print_Statistics (S : in Integer_Sets.Set) is

   C, C2 : Cursor;
   I : Integer := 1000;

begin

   if Is_Empty (S) then
     Put_Line ("<empty>");
     return;
   end if;

   C := First (S);

   loop

      C2 := Ceiling (S, I);

      while C /= C2 loop
         Put (Element (C));
         New_Line;         
         Next (C);
      end loop;

      exit when not Has_Element (C2);

      New_Line;

      I := I + 1000;

   end loop;

end Print_Statistics;

This isn't exactly what you asked for, since the inner loop will exclude
the high value from the output of the current range.  To do exactly as
you specified you'd have to use Next (Floor (S, I)) instead of Ceil (but
I think you'd also have to handle some boundary conditions, which is why
I used the simpler algorithm above).

-Matt

Re: Unified Ada library

[Georg Bauhaus]

Matthew Heaney <matthewjheaney@earthlink.net> wrote:
 
: The functions Ceiling and Floor were officially added back to the
: container library API during the ARG meeting Palma de Mallorca.

Thanks for the update.
This adds some more support for generic algorithms. Great.
 
: This isn't exactly what you asked for, since the inner loop will exclude
: the high value from the output of the current range.  To do exactly as
: you specified you'd have to use Next (Floor (S, I)) instead of Ceil (but
: I think you'd also have to handle some boundary conditions, which is why
: I used the simpler algorithm above).

It's good enough :-)

Re: Unified Ada library

[Matthew Heaney]

"Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message
news:uoen7t69b.fsf@earthlink.net...
> Matthew Heaney <matthewjheaney@earthlink.net> writes:
>
> The functions Ceiling and Floor were officially added back to the
> container library API during the ARG meeting Palma de Mallorca.
>
> I have updated the reference implementation to include most of the
> changes requested at the Palma meeting:
>
> <http://charles.tigris.org/source/browse/charles/src/ai302/>
>
> To implement the algorithm you describe above, you could do something
> like this:

See the new file test_ceiling.adb in the ai302 testdir:

<http://charles.tigris.org/source/browse/charles/src/ai302/testdir/>

I wrote a roof function to implement the exact algorithm you requested.  If
you uncomment the line that calls Ceiling (and comment the line that calls
Roof), then you can compare the behavior of each function.

-Matt

Re: Unified Ada library

[Georg Bauhaus]

Matthew Heaney <mheaney@on2.com> wrote:
: <http://charles.tigris.org/source/browse/charles/src/ai302/testdir/>
: 
: I wrote a roof function to implement the exact algorithm you requested.  If
: you uncomment the line that calls Ceiling (and comment the line that calls
: Roof), then you can compare the behavior of each function.

Yes, this is it, thanks a lot.   BTW, is the API stabilising?
What do people think about the handy Insert procedure that does without
giving back the inserted element's Cursor and the success indicator?

Re: Unified Ada library

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Matthew Heaney <mheaney@on2.com> wrote:
> : <http://charles.tigris.org/source/browse/charles/src/ai302/testdir/>
> : 
> : I wrote a roof function to implement the exact algorithm you requested.  If
> : you uncomment the line that calls Ceiling (and comment the line that calls
> : Roof), then you can compare the behavior of each function.
> 
> Yes, this is it, thanks a lot.   

You could also implement the roof function this way:

function Roof (S : Set; I : Integer) return Cursor is
   C : Cursor := Ceiling (S, I);
begin
   if Has_Element (C)
     and then Element (C) = I
   then
      return Next (C);
   end if;

   return C;
end Roof;

I think that should work.


> BTW, is the API stabilising?

Yes.  We added some stuff to the API, though, that will require an Ada95
compiler.  For example, all the generic operations are gone, and have
been replaced by non-generic operations that accept an anonymous
procedure pointer.  So instead of:

generic
   with procedure Process (C : in Cursor);
procedure Generic_Iteration (S : in Set);

we now have:

procedure Iteration (Container : in     Set;
                     Process   : access procedure (C : Cursor));

(I think that's the syntax.)


> What do people think about the handy Insert procedure that does
> without giving back the inserted element's Cursor and the success
> indicator?

I think it's a good idea, and I have to mention it to Randy.  It might
also make sense to have a Replace operation for sets, too.

-Matt

Re: Unified Ada library

[Matthew Heaney]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
> > BTW, is the API stabilising?
> 
> Yes.  We added some stuff to the API, though, that will require an Ada95
> compiler.  For example, all the generic operations are gone, and have
> been replaced by non-generic operations that accept an anonymous
> procedure pointer.  So instead of:
> 
> generic
>    with procedure Process (C : in Cursor);
> procedure Generic_Iteration (S : in Set);
> 
> we now have:
> 
> procedure Iteration (Container : in     Set;
>                      Process   : access procedure (C : Cursor));
> 
> (I think that's the syntax.)

I should also have mentioned that we made the partial view of the
container type tagged, which allows you to say:

procedure Op (S : Set) is
   procedure Process (C : Cursor) is ...;
begin
   S.Iterate (Process'Access);
end;

Re: Unified Ada library

[Matthew Heaney]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> What do people think about the handy Insert procedure that does
> without giving back the inserted element's Cursor and the success
> indicator?

You should post a message about this on the ada-comment list, so that
the ARG is officially made aware of your feature request.

(One of the reasons we provided a reference implementation was so that
we could get feedback about the API.  I too have had a need for the same
operation as you requested.)

-Matt

Re: Unified Ada library

[Marius Amado Alves]

> I wrote a roof function to implement the exact algorithm you requested...

Murphy strikes again :-) The minute you drop Roof and Ground from the 
spec a(nother) real world case shows up requiring it. ARG, we told you 
so :-)

Re: Unified Ada library

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> In the last version I saw the tag was hidden. So using inheritance for
> extension is closed.
>

Note that as of the Palma release of the container library API this is
no longer true.  All of the container types are now publicly tagged.

-Matt