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:a02:22c6:: with SMTP id o189mr5701019jao.35.1559589827322; Mon, 03 Jun 2019 12:23:47 -0700 (PDT) X-Received: by 2002:a9d:7995:: with SMTP id h21mr2230818otm.329.1559589827024; Mon, 03 Jun 2019 12:23:47 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!4no50089itm.0!news-out.google.com!l135ni33itc.0!nntp.google.com!4no50088itm.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 3 Jun 2019 12:23:46 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:3c3:401:f550:fb:deb7:d346:48a7; posting-account=JSxOkAoAAADa00TJoz2WZ_46XrZCdXeS NNTP-Posting-Host: 2601:3c3:401:f550:fb:deb7:d346:48a7 References: <28facad3-c55f-4ef2-8ef8-004925b7d1f1@googlegroups.com> <12ffe476-35a7-4442-994e-9a03972619bc@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2276685b-0e6b-46d1-ae7e-e7f1c0781dc0@googlegroups.com> Subject: Re: Why .ads as well as .adb? From: John Perry Injection-Date: Mon, 03 Jun 2019 19:23:47 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56447 Date: 2019-06-03T12:23:46-07:00 List-Id: On Monday, June 3, 2019 at 9:50:03 AM UTC-5, Niklas Holsti wrote: > > "teams can work separated from each other as needed, without the > > project having to distribute all of the implementation to everyone" > > > > [Having separate specification files against which one can *compile* > > would be useful, not just convenient, though I think it's arguable > > that one can do this in Oberon, too, via .smb files and > > documentation.] >=20 > If an Ada project needs to use an Ada library that is not open-source=20 > and was developed by someone else, the library provider can deliver the= =20 > .ads source files to define the library API, but deliver only the object= =20 > code for the .adb files, thus keeping the library implementation secret.= =20 > Can Oberon .smb files do that? Yes; that's the entire point of an .smb file. The Oberon compilers I'm fami= liar with generate both symbol (.smb) and object files (.o or .class, depen= ding on the target). I've tested that they will check a module against .smb= , without having an object file. In Native Oberon, unexpected record fields are kept secret [1]. Wirth state= s in "Modula-2 and Oberon" [2] that symbol files have an advantage over sou= rce files, in that the compiler can record a version number with the file, = and automatically update it. > In Ada this can be done even if the library is actually implemented in=20 > some other language such as C. An Oberon compiler that targets native code allows one to create modules th= at define interfaces to C files [3]. Another, which targets the JVM, allows= one to create modules that define interfaces to Java class files. [4] > When I write client code for a package, I find it much more convenient=20 > to study the package's interface from its .ads file, because the .ads=20 > file is usually shorter than the .adb file and contains only information= =20 > useful to the client (up to the "private" part). However, I admit that a= =20 > smart IDE could display a filtered view of a "combined .ads/.adb" file,= =20 > showing me only the interface and not the implementation. Right, this latter is what I'm referring to in general. > That is true, IMO, for current Ada, but I'm sure that Ada could be=20 > extended with pragmas or keywords to allow a combined .ads/.adb file=20 > from which a "pure .ads" could be extracted. But I don't see any=20 > advantage in that, given the other advantages of separate .ads and .adb. That's fine; as I said, I'm curious. I've noticed that Ada's designers aren= 't reticent to adopt what they think are good ideas from other languages (e= .g., Eiffel's contracts) so that made me wonder why the .ads/.adb distincti= on was retained, at least in gnat. (I'm not actually aware if that's requir= ed by the language itself.) > No, gnatchop reads a source file that is a simple concatenation of any=20 > number of .ads and .adb files, and just finds the boundaries of the=20 > concatenated files and spits out the separated (de-concatenated) files.= =20 > It is a bit like "unzip" but uses Ada syntax to separate out the=20 > individual files from the "archive" (the concatenated file). >=20 > Ada compilers other than GNAT accepted such concatenated input source=20 > files as "compilations". Gnatchop was implemented to help apply GNAT to= =20 > such source files. I completely misunderstood that. Thank you. BTW, in case it hasn't been clear: there are plenty of ways I think Ada is = far superior to Oberon. This is just one aspect of Oberon that originally I= didn't like (when I was a Modula-2 programmer), and came to appreciate gre= atly only later. john perry [1] inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.doc [2] www.ethoberon.ethz.ch/native/compiler/obj081200/ObjectFile.html [3] miasap.se/obnc/man/obnc.txt; see "Interfacing to C". [4] github.com/lboasso/oberonc