Re: memory management in Ada: tedious without GC?

On Sat, 24 May 2008 16:52:03 -0400, Robert A Duff wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> writes:

Yes, this why it is safe to assume that the program may not rely on it.

Such assumptions are never safe, because programmers make mistakes.

That is why Ada should be picky. I prefer to qualify such programs as
erroneous and allow the compiler to reject them. This is independent on
whether we would fix the order or not.

Yes, this is the same dilemma as with re-ordering operands in expressions.

I don't like the permission to reorder operands, either.
But at least for that, there's a legitimate efficiency concern.
For finalization, I seriously doubt that the permission
to reorder has any significant efficiency benefit.

type X is record
A : Boolean := False;
B : Integer := 1;
C : Boolean := False;
end record;

May the compiler group A and C and initialize both them by zeroing memory?
If the initialization order were fixed, that would be illegal to do.

I understand your argument, but I think that the solution is wrong. I'd
prefer a better control over the side effects in order to make such
(erroneous) programs illegal. It is especially important for modern
pipelined, multi-core architectures. Why not to perform initialization of
components concurrently?

Sure, if the compiler can prove there are no side effects,
it can reorder, intersperse, and/or do things in parallel.
In that case, "in declaration order" and "in implementation-defined
order" are equivalent rules.

Yes, this could be the ground for a compromise. Let us introduce pure
subprograms, not as a pragma Pure, but as a contract.

Now, the components are initialized by pure subprograms can be in any order
when they are siblings. Others are initialized in their declaration order.

But this is a much bigger change to Ada.

The compiler would not need to prove anything. That would be the
programmer's responsibility to ensure purity of an implementation. Of
course, a decent compiler would make some reasonable checks, but it would
be sufficient to verify that pure bodies do not call impure ones. Surely, a
pure primitive operation could not be overridden by an impure one, etc.
That does not look much intrusive.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: OT: Requesting C advice
    ... some behind the scenes action of the compiler. ... In fact the memory could ... Proper initialization means that floats and doubles must be initialized to 0.0 and pointers must be initialized to the null pointer value, even if those bit patterns differ from all-bits-zero. ...
    (Fedora)
  • Re: left-to-right (was In-Out Parameters for functions)
    ... >> The question is what gets lost if an evaluation order is fixed. ... What I would expect from a good compiler is factoring out the cycle ... There is no need to check program semantics very precisely. ... language may simply outlaw "pure" functions like: ...
    (comp.lang.ada)
  • Re: In a Pascal-like language, would being able to declare a subroutine as "purely functional" b
    ... "Compiler, this is what I intend, now ... Look up "pragma Pure". ... (a pure function can't call an impure one). ... not modified in the loop, it can move the call outside the loop. ...
    (comp.compilers)
  • Re: I think C# is forcing us to write more (redundant) code
    ... static void F(out string s) ... >> compiler enforced). ... locals here and locals are stack allocated, ... I don't have a problem with this explicit initialization in the current ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: pointer and storage
    ... But, as always, a compiler is free to issue any diagnostics it ... If the initialization is executed, it invokes undefined behavior. ... In old versions of the C language, before "const" was introduced, this ...
    (comp.lang.c)