Re: Languages don't matter. A mathematical refutation

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

On 09.04.15 11:38, Dmitry A. Kazakov wrote:

>> (Or else, at least provide more efficient, more predictable containers
>> based on contracts. ;-)

I mentioned containers because Randy reminded us of
their usefulness as automatic storage managers.
(Containers with contracts have already appeared in GNAT.)

> And the smiley means? You certainly know that there is no way to contract
> [*] GC.

It seems possible to guarantee certain properties of GC.
That's the supplier's side of the contract.

Properties of the collection process can be abstracted
into mathematical estimates, and reliably so, I think.
Consider

   pragma Suppress

The idea of suppressing checks, if "ported" to containers
could be based on observing the container's expectations:
First,

    Container: "Don't do This!
      Because I will be assuming v(This) = False."

The algorithmic "conclusion" then becomes that all checks
that Ada normally associates with This can be Suppressed.
(Tampering, cursors carrying their containers, etc.)

That's the first win. It depends on contracts and clients
being written accordingly.

Now, WRT storage management, assume a bounded container.
The implementation may pre-allocate the maximum number of
objects.(*) Given that, why should it not be possible at all,
in no case, to guarantee a known complexity of storage
management? A bounded vector, say, could specify its
storage management needs, on condition that ... Much like
a hash table package would state that

   "As long as the number of slots is as least N/M,
    finding an object will take no more than f(M, N, g(Hash))."

Thus, if every 5 timeslices, 3 are needed for working with
the data stored in the container, and this container instance
guarantees that maximally 1 timeslice is needed for all possible
storage management cases, there is 1 left for any lags.


> GC is non-functional and unrelated to the program behavior, which is
> another way to explain why GC is neither low nor high level. It is
> non-existent.

Like everything that actually handles program data, GC does
influence the program's behavior, e.g. by taking time.
Hence, one may influence GC in server JVMs, for example.
But that's the point. Suppose there is an abstract description
of GC behavior, in terms of parameters. Will the description
be sufficiently detailed for guiding the design of an algorithm?

__
(*)For the sake of simplicity, WLOG. (I think GNAT's variant
records are similar.)