ASCL project on AdaPower.net

ASCL project on AdaPower.net

[Nick Roberts]

I'm delighted to announce that a nascent ASCL (Ada Standard Component
Library) project has been set up at:

http://www.adapower.net/ascl/

Many thanks to David Botton.

I'd like this to be the 'home' of the project for the foreseeable future,
and I'd like to extend an invitation to anyone who wishes to contribute:

designs (unit specs and /or documentation);
implementations (unit bodies and/or documentation);
general ideas, comments, kudos, etc.;
anything else relevant.

If so, please e-mail me:

nickroberts@adaos.worldonline.co.uk

The issue of licence comes up again: I suggest that everything put onto the
ASCL site is published under the GPL/LGPL/GMGPL/GPDL. (The ACL seems a
possible alternative.)

--
Nick Roberts

Re: ASCL project on AdaPower.net

[Pascal Obry]

Just a style note. I think that the ASCL sources should follow somehow the
convention used in the RM. Or maybe the GNAT style enforced by -gnaty.

For example I would change:

   function Cursor_Index (
         Source : in     Bounded_List;            
         Cursor : in     Cursor_Number := 1;      
         Facing : in     Direction     := Forward ) 
     return Natural; 

To (RM / GNAT style)

   function Cursor_Index
     (Source : in Bounded_List;            
      Cursor : in Cursor_Number := 1;      
      Facing : in Direction     := Forward)
     return Natural; 

Or (RM style)

   function Cursor_Index (Source : in Bounded_List;            
                          Cursor : in Cursor_Number := 1;      
                          Facing : in Direction     := Forward)
     return Natural; 

Or more GNATish style:

   function Cursor_Index
     (Source : in Bounded_List;            
      Cursor : in Cursor_Number := 1;      
      Facing : in Direction     := Forward) 
      return      Natural; 

Just my 2cents,
Pascal.


-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: ASCL project on AdaPower.net

[Preben Randhol]

On 02 Dec 2001 11:53:49 +0100, Pascal Obry wrote:
> Or (RM style)
> 
>    function Cursor_Index (Source : in Bounded_List;
>                           Cursor : in Cursor_Number := 1;
>                           Facing : in Direction     := Forward)
>      return Natural; 

I would say I like this style most (hmm I'll start using it myself too)
as it is easy to see what the function returns and which arguments are
needed in just a quick glance.

> Or more GNATish style:
> 
>    function Cursor_Index
>      (Source : in Bounded_List;
>       Cursor : in Cursor_Number := 1;
>       Facing : in Direction     := Forward) 
>       return      Natural; 

I don't like this much as it is harder or read fast. 

Preben
-- 
                 �For me, Ada95 puts back the joy in programming.�

Re: ASCL project on AdaPower.net

[Preben Randhol]

On Sun, 2 Dec 2001 11:37:13 +0000 (UTC), Preben Randhol wrote:
> I don't like this much as it is harder or read fast. 
                                         ^^
                                         to

-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: ASCL project on AdaPower.net

[Jeffrey Carter]

Nick Roberts wrote:
> 
> I'm delighted to announce that a nascent ASCL (Ada Standard Component
> Library) project has been set up at:
> 
> http://www.adapower.net/ascl/
> 
> Many thanks to David Botton.
> 
> I'd like this to be the 'home' of the project for the foreseeable future,
> and I'd like to extend an invitation to anyone who wishes to contribute:
> 
> designs (unit specs and /or documentation);
> implementations (unit bodies and/or documentation);
> general ideas, comments, kudos, etc.;
> anything else relevant.

Feel free to add

PragmARC (spec)
PragmARC.List_Unbounded_Unprotected (spec and body)

If so inclined, you could also add

PragmARC.List_Unbounded (spec and body)

-- 
Jeffrey R. Carter
PragmAda Software Engineering

Re: ASCL project on AdaPower.net

[Ted Dennison]

In article <9ucgi0$7g2i6$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>The issue of licence comes up again: I suggest that everything put onto the
>ASCL site is published under the GPL/LGPL/GMGPL/GPDL. (The ACL seems a
>possible alternative.)

I purposedly did *not* put a license on anything, just because I wanted to avoid
that issue for now. I'm afraid anything other than complete public domain might
cause a problem for a vendor somewhere, and that's the last thing we want.

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

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

Re: ASCL project on AdaPower.net

[Ted Dennison]

In article <9ucgi0$7g2i6$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>I'm delighted to announce that a nascent ASCL (Ada Standard Component
>Library) project has been set up at:

I guess ASCL is OK as a placeholder, but the name was one of the things we were
still debating. I'm on record against meaningless acronyms like ASCL.

>http://www.adapower.net/ascl/

As to the "requirements" on that page:

To make this more requirement like, all the "to be" verbs need to be changed to
"shall" (indicating a must have) or "should" (indicating a nice-to-have). Unless
otherwise stated, they need to be "shall"s.

On 3, all of the "to be" verbs should be changed to "should"s.

5 and 7, and 8 are just flat-out wrong. (7 and 8 could be another "need not
support").

10 is really a new one about arrays. Since its a should, its phrased correctly.

12 is new. I'm not familiar enough with any such environments to know what this
even means.

13 is also wrong. This should be changed to a "need not" (however we can phrase
that in should/shall lingo).

As a general comment, I notice a lot of stuff in that fourth column I'd disagree
with. While some of this might be new for those who haven't been following the
whole thread in all its various forms, pretty much everything in there has
already been discussed to death and (IMHO) consensus arrived at. The exceptions
to this are points 10 and 12. But both of them should probably be made
"should"s, and in that form I don't think they are particularly contraversial
either.

Just to restate my position, I don't think we need a set of requirements to vote
on (at least not these; new ones perhaps...). Instead, what we need a *the* set
of requirements written down, where we can point newcommers (and possibly
provide an explanation why). We certianly don't need the amount of "further
dicussion" implied by the fourth column on that page. In fact, words cannot
express how much we don't need that. :-)

Here's what I think *is* still up for discussion.

*  The name of the facility.

*  How safe iterators need to be. I think consensus is starting to move to
completely safe (for unbounded anyway).

*  The naming scheme for accessing the ends, and for iterating.

*  The precise subprogram-for-subprogram composition of the package spec.


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

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

Re: ASCL project on AdaPower.net

[Larry Kilgallen]

In article <ZoMO7.46863$xS6.76244@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:

> I purposedly did *not* put a license on anything, just because I wanted to avoid
> that issue for now. I'm afraid anything other than complete public domain might
> cause a problem for a vendor somewhere, and that's the last thing we want.

Thank you.

Re: ASCL project on AdaPower.net

[Ted Dennison]

In article <44NzFiXte$g0@eisner.encompasserve.org>, Larry Kilgallen says...
>
>In article <ZoMO7.46863$xS6.76244@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
>
>> I purposedly did *not* put a license on anything, just because I wanted to 
>> avoid that issue for now. I'm afraid anything other than complete public 
>> domain might cause a problem for a vendor somewhere, and that's the last 
>> thing we want.
>
>Thank you.

Well, don't be so quick. Not having any license pretty much means no one but me
has any rights to it whatsoever. :-)  However, I can change that at a moment's
notice, when we decide what's best.

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

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

Re: ASCL project on AdaPower.net

[Nick Roberts]

I'm not saying, I'm only suggesting, but possibly it would be more
appropriate for the whole PargmARCs to be mirrored on (or even moved to)
AdaPower.net.

I can't speak for him, but I suspect David B would be very happy to do this.

In particular, there are many units in the PragmARCs that are out of the
scope of ASCL but which I am certain a lot of people would find extremely
useful.

--
Best wishes,
Nick Roberts


"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C0A6B0E.119BAEF9@acm.org...
> Feel free to add
>
> PragmARC (spec)
> PragmARC.List_Unbounded_Unprotected (spec and body)
>
> If so inclined, you could also add
>
> PragmARC.List_Unbounded (spec and body)

Re: ASCL project on AdaPower.net

[Nick Roberts]

Fair enough. I'll adopt this position until someone argues (convincingly)
otherwise.

I'll maintain my "for the purposes of the ASCL" copyright on my submissions,
with the solemn promise that I will devolve them to the public domain if and
when (it is clear) they are accepted.

--
Nick Roberts


"Ted Dennison" <dennison@telepath.com> wrote in message
news:ZoMO7.46863$xS6.76244@www.newsranger.com...
> I purposedly did *not* put a license on anything, just because I wanted to
avoid
> that issue for now. I'm afraid anything other than complete public domain
might
> cause a problem for a vendor somewhere, and that's the last thing we want.

Re: ASCL project on AdaPower.net

[Jeffrey Carter]

Regarding the "Conclusion" column on this web page, several do not seem
to reflect the consensus that had been reached here:

4. We had reached a consensus of No, so this should be Rejected.

6. Consensus was Yes, so this should be Accepted.

7. No -> Rejected

8. No -> Rejected. This is related to 7.

9-13. Invented by NJR after consensus had been reached on 1-3 and 5-8.

At this point it would probably be most productive to ignore 9-13 and
reach a consensus on 4. Then we should agree of a package specification
implementing those requirements.

-- 
Jeffrey Carter

Re: ASCL project on AdaPower.net

[Jeffrey Carter]

Nick Roberts wrote:
> 
> I'm not saying, I'm only suggesting, but possibly it would be more
> appropriate for the whole PargmARCs to be mirrored on (or even moved to)
> AdaPower.net.
> 
> I can't speak for him, but I suspect David B would be very happy to do this.
> 
> In particular, there are many units in the PragmARCs that are out of the
> scope of ASCL but which I am certain a lot of people would find extremely
> useful.

There is already a mirror of the web page on adapower.com. I don't know
what the difference is between it and adapower.net, but we would have no
objection to this.

However, the PragmARCs are distributed as a zip file containing the
entire library, test and example programs, and so on. For the purposes
of discussing a standard list library, I thought it might be simpler for
some people to have those 3 (or 5) files directly linked to as text.

-- 
Jeffrey R. Carter
PragmAda Software Engineering

Re: ASCL project on AdaPower.net

[Ted Dennison]

In article <3C0BFCDC.9F287EED@boeing.com>, Jeffrey Carter says...
>9-13. Invented by NJR after consensus had been reached on 1-3 and 5-8.

The only one in there that is *completely* new to me is 12. The rest were at
least discussed here a smidge.

>At this point it would probably be most productive to ignore 9-13 and
>reach a consensus on 4. Then we should agree of a package specification

Personally, I think we allready have it on 4. The idea is that there is no
synchronization provided in the facility, but things are made reentrant and it
works with tasks at least as well as Ada.Text_IO does. I think that is what he
was trying to express in 4 (at least I hope so). I wasn't aware that any further
discussion was needed on this point.

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

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

Re: ASCL project on AdaPower.net

[Jeffrey Carter]

Ted Dennison wrote:
> 
> >At this point it would probably be most productive to ignore 9-13 and
> >reach a consensus on 4. Then we should agree of a package specification
> 
> Personally, I think we allready have it on 4. The idea is that there is no
> synchronization provided in the facility, but things are made reentrant and it
> works with tasks at least as well as Ada.Text_IO does. I think that is what he
> was trying to express in 4 (at least I hope so). I wasn't aware that any further
> discussion was needed on this point.

You're right. I got my numbers mixed up. The one without consensus yet
is 2 (lists must be 100% safe).

Sorry for the confusion.

-- 
Jeffrey Carter

Re: ASCL project on AdaPower.net

[Ted Dennison]

In article <3C0CF34B.89719EDB@boeing.com>, Jeffrey Carter says...
>
>You're right. I got my numbers mixed up. The one without consensus yet
>is 2 (lists must be 100% safe).

Ahhh yes. That's quite true. However, I think I was one of the main folks in the
anti-safe contingent, and I'm willing to cede the point now. Perhaps the (any?)
others will too, after looking over the a new interface using it.

I have a new strawman version that I'm not going to have a chance to post until
tonight, unfortunately. This version, among other changes, will present a safe
iterator solution. It also addresses a lot of the other issues. If we can get
general agreement on this approach, and on the new naming scheme and some of the
other little issues, we may be able to move forward from it to the next phase. I
have high hopes (perhaps soon to be dashed) that this is what will occur. At
worst, I'm hoping it won't need more that one more *minor* revision.

This new version does not adopt some of the things that Nick has been pushing
for; certianly not his iterator approach. However it actually does owe a great
deal to Nick's input here, and to his SCL work. So I don't want Nick thinking I
feel his input has been unwelcome or unhelpful, because in fact quite the
opposite has been true.

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

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

Re: ASCL project on AdaPower.net

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> Just to restate my position, I don't think we need a set of requirements to vote
> on (at least not these; new ones perhaps...). Instead, what we need a *the* set
> of requirements written down, where we can point newcommers (and possibly
> provide an explanation why). We certianly don't need the amount of "further
> dicussion" implied by the fourth column on that page. In fact, words cannot
> express how much we don't need that. :-)

Well, I only count six people voting, and they haven't voted on all
the requirements. I find that too small to count as "concensus". I
guess I'm into a more formal process than you are :).

-- 
-- Stephe

Re: ASCL project on AdaPower.net

[Stephen Leake]

Ted Dennison<dennison@telepath.com> writes:

> In article <3C0BFCDC.9F287EED@boeing.com>, Jeffrey Carter says...
> >9-13. Invented by NJR after consensus had been reached on 1-3 and 5-8.
> 
> The only one in there that is *completely* new to me is 12. The rest were at
> least discussed here a smidge.
> 
> >At this point it would probably be most productive to ignore 9-13 and
> >reach a consensus on 4. Then we should agree of a package specification
> 
> Personally, I think we allready have it on 4. The idea is that there is no
> synchronization provided in the facility, but things are made reentrant and it
> works with tasks at least as well as Ada.Text_IO does. I think that is what he
> was trying to express in 4 (at least I hope so). I wasn't aware that any further
> discussion was needed on this point.

Hmm. How about this definition for "done debating": 

10 people have voted, and a majority of 7 agree on the answer

-- 
-- Stephe

Re: ASCL project on AdaPower.net

[Nick Roberts]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C0C375F.D53EC81D@acm.org...
> However, the PragmARCs are distributed as a zip file containing the
> entire library, test and example programs, and so on. For the purposes
> of discussing a standard list library, I thought it might be simpler for
> some people to have those 3 (or 5) files directly linked to as text.

No problem. Will do.

--
Nick Roberts

Re: ASCL project on AdaPower.net

[Marin David Condic]

If the interest is to get the widest possible usage out of it (and I think
that's a noble goal) then public domain is probably the best choice. Or at
least something as unrestrictive as that which the ARM was published under.
(We want to get it into the ARM eventually, don't we?) Public domain would
make it extremely easy for professors to include it in their textbooks or
for implementors to build on top of it or for compiler vendors to distribute
it. There's no real money to be made in something like this from the
perspective of "selling" the library and anything that might be some flavor
of the GPL might only be there to attempt to coerce source code
distribution - which some end users might find objectionable. I'd suggest
just turning it loose like a live Grateful Dead concert and let it go where
it may.

But you're right that this is an issue best dealt with after we have an
initial cut at the spec - which I see as a kind of "Requirements Doc". It
may need to be dealt with prior to producing a working version of the
library. Those contributing to the implementation may want to understand
what restrictions - if any - are likely to be placed on their work.
(Presuming that anyone wishing to contribute agrees to some general goal of
maximum possible openness & utilization, there can still be some debate
about the best mechanism to get there.)

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


"Ted Dennison" <dennison@telepath.com> wrote in message
news:ZoMO7.46863$xS6.76244@www.newsranger.com...
>
> I purposedly did *not* put a license on anything, just because I wanted to
avoid
> that issue for now. I'm afraid anything other than complete public domain
might
> cause a problem for a vendor somewhere, and that's the last thing we want.
>