From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:a5e:940b:: with SMTP id
 q11mr37599694ioj.251.1560120024270;
        Sun, 09 Jun 2019 15:40:24 -0700 (PDT)
X-Received: by 2002:aca:4853:: with SMTP id v80mr10077237oia.78.1560120024080;
 Sun, 09 Jun 2019 15:40:24 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!g15no631083itd.0!news-out.google.com!l135ni708itc.0!nntp.google.com!g15no631077itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 9 Jun 2019 15:40:23 -0700 (PDT)
In-Reply-To: <lypnnm4ez7.fsf@pushface.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2601:3c3:401:f550:3d6d:6db5:dda4:ab9b;
 posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS
NNTP-Posting-Host: 2601:3c3:401:f550:3d6d:6db5:dda4:ab9b
References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com>
 <qcvqut$ejh$1@gioia.aioe.org>
 <dbbcf7b1-091f-4c87-b2b1-021bb9503b70@googlegroups.com>
 <qd2krk$pin$1@gioia.aioe.org>
 <f37f6f75-62d4-4152-917e-d666d67f6cb7@googlegroups.com>
 <qd6rb8$hl7$1@franka.jacob-sparre.dk>
 <a902e41a-729d-4c00-8e3f-0cda1822a349@googlegroups.com>
 <qd81gq$aej$1@dont-email.me> <87woi0xtwm.fsf@nightsong.com>
 <glpiqeFt9jqU1@mid.individual.net>
 <f611bdb8-5a40-48bd-afe5-17de72bbe193@googlegroups.com>
 <glq1rpF1v52U1@mid.individual.net>
 <4a0438de-1f1d-4469-aae4-908854d378ea@googlegroups.com>
 <qdbvth$3db$1@franka.jacob-sparre.dk>
 <47d02bdc-6b50-43aa-bc5d-bb5b6225f5bd@googlegroups.com>
 <455333f0-ede4-4833-900a-240a499395ac@googlegroups.com>
 <875zphvufc.fsf@nightsong.com>
 <ln1s03sqkt.fsf@kst-u.example.com> <87y32bvbeo.fsf@nightsong.com>
 <lno936r3jw.fsf@kst-u.example.com>
 <561c766c-4f9c-432c-be9b-822dd9c3c8ba@googlegroups.com>
 <lypnnm4ez7.fsf@pushface.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ee3c5a44-e2cd-4997-b62b-90489820ec97@googlegroups.com>
Subject: Re: Why .ads as well as .adb?
From: John Perry <john.perry@usm.edu>
Injection-Date: Sun, 09 Jun 2019 22:40:24 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader01.eternal-september.org comp.lang.ada:56593
Date: 2019-06-09T15:40:23-07:00
List-Id: <comp.lang.ada>

On Sunday, June 9, 2019 at 4:37:49 PM UTC-5, Simon Wright wrote:
> > I imagine that [1] was generated by some software tool.
> 
> But not from an implementation. It's a reference manual, after all, a
> specification, and it goes into much more detail than your example ...

This gets back to one of my earlier questions, which I don't think was answered. (Apologies if it was; I've tried to follow everything.) You point out that it's a specification, but that's not a spec file, right?

If I understand correctly, I salute the culture that produces such a specification. The question, however, relates to the separation of spec file from implementation file. Was that generated from a spec file; i.e., an .ads?

> ... well, I don't know Eiffel, so I can't really tell, but the first
> thing I see is
> 
>    description: 
>       "Binary search trees; left child item is less than current item,
>       right child item is greater"
> 
> and I ask myself, does this mean that there can't be equal elements in
> the tree?

I think this is beside the point? That's not a function of spec files versus implementation files, is it?

> > [1] http://www.ada-auth.org/standards/12rm/html/RM-TOC.html
> 
> This is the most up-to-date:
> http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TOC.html

Thank you!