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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: GNAT GPL is not shareware
Date: Mon, 12 Jan 2015 15:52:35 +0100
Organization: A noiseless patient Spider
Message-ID: <m90n2n$c2p$1@dont-email.me>
References: <87bnmetex4.fsf@ludovic-brenta.org>
 <ohGqw.195991$rq4.58661@fx27.iad>
 <fa17b731-a99f-4d51-b7e9-806bb2de00c6@googlegroups.com>
 <s7Jqw.1026393$Lj7.973937@fx22.iad>
 <alpine.DEB.2.11.1501061414310.19142@debian> <m8gtr1$rg1$1@dont-email.me>
 <m8h6gn$202$1@dont-email.me> <iWXqw.180018$Sn4.103298@fx10.iad>
 <m8hj8p$qn2$1@dont-email.me> <FIYqw.1051175$FX2.802392@fx18.iad>
 <m8j3k5$gr9$1@dont-email.me> <qcdrw.1246475$Y4.224981@fx24.iad>
 <m8kd1u$lkc$1@loke.gir.dk> <1otenmcbgnvlt$.dn9361nl2jm8$.dlg@40tude.net>
 <m8lnlg$eat$1@dont-email.me> <8ryfky4awox2$.q2gfw4pvsgau.dlg@40tude.net>
 <m8m3ge$sg3$1@dont-email.me> <v7sijsm038wt.rnnn8jo6j2nj$.dlg@40tude.net>
 <m8om3v$2ga$1@dont-email.me> <wvb5ss3jb7w4$.y08ot3r2io2m$.dlg@40tude.net>
 <m90br5$13p$1@dont-email.me> <delkd2xhimol.q5uw34dwvc8m.dlg@40tude.net>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 12 Jan 2015 14:52:07 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="12377"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19GwSCyvH+ToLhlEvuLv5tZldGP6CGvtyA="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <delkd2xhimol.q5uw34dwvc8m.dlg@40tude.net>
Cancel-Lock: sha1:jov+bwVkq6BpyvpnCyTGFcGutbg=
Xref: news.eternal-september.org comp.lang.ada:24549
Date: 2015-01-12T15:52:35+01:00
List-Id: <comp.lang.ada>

On 12.01.15 14:21, Dmitry A. Kazakov wrote:
> On Mon, 12 Jan 2015 12:40:50 +0100, G.B. wrote:
>
>> On 10.01.15 08:18, Dmitry A. Kazakov wrote:
>>> Just because RDBMS uses RA for dealing with persistency problems.
>>
>> Persistence typically is just one of the goals when using a DB.
>
> Other goals, like money extortion, you mean?

A DB is good for independent information retrieval,
in particular when it is part of a PL:

Clients then need not buy or order special information
retrieval programs given all these non-standard databases.
A clear advantage, IMO.

Tiny example:
.ali files of GNAT and the ./info files of AdaMagic may
(theoretically) share a schema of Ada library data,
data available on request, leaving hardly any performance hit.

Granted, there was a time when a standard schema like this
would have meant that two vendors of Ada compilers would
be able to use each others' output (other than the object files).
And even third parties could use either GNAT's or AdaMagic-Based's
compiler output, so as to make it serve *their* needs as well
as *their* customers' needs. That's not exactly the freedom of
information that every business person will like, I guess,
depending on whether they are sellers or buyers.


> And it would be a lie to say that SQL were any
> declarative.

SQL is not *any* declarative? Do you mean "not *all* declarative"?

> Nobody would seriously consider this
> for universal purpose programming, except for pointy-haired academics.

So what? No need to have relational models replace everything!
That's a straw man. When RA is just made available as part
of a general purpose PL's definition, that's a good start.

In fact, with either built-in relation support or Ada.Containers,
a typical algorithm like
   "Find all friends of distance <= 2."
might look almost the same no matter whether, say, pairs would
be stored in a container table or in a relational table.