Re: Proposed change to BC iterator parameters [limitedness]

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

amado.alves <amado.alves@netcabo.pt> wrote:
: <<Sometimes I dearly wanted limited records but was defeated
: by the library that could not store them (storing them was the
: intention):...>>
: 
: I think there are (container) libraries that accept limited
element types.

Charles does (some of it).

: And some libs that dont can easily (?) be changed
: in that direction.  But as I indicated I think it is 'unatural'
: to store values of a limited type. For me it does not make sense
: to put constants in a container. So my advice can only be: rethink
: your program.

I tried, limitedness is only an implication of having access
discriminants in tagged types, which fulfil the requirements
(see type T below):
- "There are three constant links to other objects in these objects".
- "You will have to provide initial values for these links, we cannot
   have dangling pointers here.".

given

  type T
    (look_here: access D;
     look_there: access E;
     and_also_over_there: access D)
  is tagged limited
      record
	 variable_part_1: Some_Type;
	 variable_part_2: Some_Other_Type;
      end record;
   
  ...

The thing is not that I want to store constant instances of
T, I will have to have instances available with both constant
component parts and variable component parts, as above.  To me,
this type seemed natural.  Or is it not, given the requirements
from above?

Where do I store these instances? They must live somewhere...

The "solutions" I have now are using a _comment_ indicating that
clients _should_ use a constructor function, here is one of the
solutions that doesn't use pointers to T objects:

   type T is tagged private;
   --  use make!

   function make
    (look_here: D;
     look_there: E;
     and_also_over_there: D) return T;

where the full view of T contains pointer fields, and make provides
'(unchecked)_access values for them.  But "--  use make!" is not
enforcable by a compiler, while

   type T(<>) is tagged limited private;

or some such will not allow me or anyone else to declare T objects
without initialisation (for any access parameters). Which is what
I found desirable, I can then rely on the language and assume
that T instances will have been initialised, without relying on
programmers obeying a comment about a related function.


I'm stuck.
(Thinking around corners: deriving a definite T from Controlled
inside a generic wich has make(...) from above as a formal subprogram
wich is then called during Initialise of T?  Phew...)

-- Georg