Re: GNAT GPL is not shareware

["G.B." <bauhaus@futureapps.invalid>]

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.