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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: GNAT GPL is not shareware Date: Fri, 09 Jan 2015 14:47:08 +0100 Organization: A noiseless patient Spider Message-ID: References: <87bnmetex4.fsf@ludovic-brenta.org> <79f3eff7-2b45-40ae-af94-fa9a17426d82@googlegroups.com> <87bnmd8mg2.fsf@ixod.org> <19cf9bc2-f8b9-4735-b427-7b070dda59da@googlegroups.com> <1otenmcbgnvlt$.dn9361nl2jm8$.dlg@40tude.net> <8ryfky4awox2$.q2gfw4pvsgau.dlg@40tude.net> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 9 Jan 2015 13:46:39 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="2570"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+nGS47sVr3Ibatj7RBA47y/ojYpSBdUM8=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Cancel-Lock: sha1:neEL9D8Dvfh0XGyHbqwzqZlGDUk= Xref: number.nntp.giganews.com comp.lang.ada:191807 Date: 2015-01-09T14:47:08+01:00 List-Id: On 08.01.15 17:54, Dmitry A. Kazakov wrote: > On Thu, 08 Jan 2015 15:17:15 +0100, G.B. wrote: > >> The same setup could be used for a database of Ada identifiers >> and possible relations among them, since each of the identifiers, >> as the word "identifier" says, denotes identically one element of >> the universe of named things that an Ada source establishes. > > This is obviously wrong, since units can be instantiated, recursively used, > objects have scopes and life time. "Identifier", which denotes a source entity uniquely. It's about a database of things in the source text, not about things at run-time. > Which "Universe" you mean for an identifier X declared in a body of a task > type? package body P is task body Foo is X : T: -- here procedure Bar is X : T; -- here, too begin ... yields P.Foo.X P.Foo.Bar.X Whenever profiles will matter, too, X being a subprogram, say, they become part of identification, as usual. No identifier identifies two things of the source text. GNAT, like other compilers, collects the identifiers in its vendor specific database, called .ali files… >>> Relational algebra (RA) can be implemented in Ada. No problem, >> >> You *are* naming the problem: >> >> It is: "reinventing wheels", as I said. > > No more than other container types are. Other languages have built-in syntax and semantics for both containers and operators for handling relations (SETL, APL, Prolog, …). Ada, like C++ and others, suggests a library based approach; at least some of the effort is standardized. > RA, to build a programming paradigm upon, is known to be unusable. RA is a mathematical abstraction without transitive closure of relations. That's not the same thing as what people mean by relational model. These even have recursion, or, if *used*, that use is typically very well supporting full languages (be that Ada or stored procedures or whatever). > Which is > the rationale behind Randy's empirical conclusion about databases. His conclusions are not about using relational models, but about using foreign RDBMSs. Not the same thing. >> The point is that relational >> problems can be solved easily whenever a language defines the means >> of directly expressing relational items. > > Another point is that relational problems are not domain space problems. Another false generalization, IMO: we would have a political discussion at best, about "domain space". I had just listed one example, others have given more. > RA > requires bending original problems into a very narrow framework of > techniques, inefficient and counterintuitive. Certainly, relational techniques do sometimes apply, and are much more efficient to use than developing home-brewed data structures and algorithms. All the more when these will fact fact approximate the relational model. > DB models have practically zero reuse and are extremely unmaintainable as > compared to other software. This interesting claim ignores that databases frequently do solve problems, such as (a) storing data for many different, independent uses and (b) finding (relations between) data items as well as computed items, both foreseen and unforeseen. Both are real needs. > That is because DB design focus on raw data, rather than on higher level > entities. Your assumption is irrelevant, insofar as, briefly, no program can do anything real without data. (And yes, if theorizing, you can even involve executable objects in a relational model, reflecting the phrase "algorithms = data".) >>> Relational algebra does not deploy universally qualified expression. >> >> Every selection is from the next universe, all of it. What definition >> of the RA equivalent of FROM are you denying? I don't understand. > > What is FROM for Ada identifiers? As outlined above, all identifiers in source of a given Ada program would be one simple example: I can use my finger and point at every one of these identifiers, one by one, thereby enumerating them. This establishes one possible universe for use with FROM.