Re: Can't export object of private type

[fraser@synopsys.spam.me.at.your.peril.com]

I nearly cried when nospam@thanks.com.au said:

(Oh, it's nothing personal (the tagline) btw, I'm just very sensitive
like that.  Maybe it's time to change it)

>Sam Mize wrote:

>:This requires different syntax in C ("@" and "." versus "->", IIRC).

>Doesn't sound nice. :)

It sucks.  Imagine, for a moment, deciding to change a stack object to
an allocated one.  It's happened to me, and it hurts.  A lot.


[Sam]
>:In a case like this, it's unlikely you are making a mistake, so Ada
>:assumes you want the implicit ".all".

>:On the other hand, mis-using a pointer to a scalar is a common
>:error, so Ada doesn't infer any de-references -- you have to do
>:them manually.

I think it goes deeper than that.  From a data abstraction point of view,
you're using an object as a gateway, or a guide, to find what you really
want, a record component or an array element for example.  Whether the
gateway is on the stack or on the heap (I'm simplifying here)
should make no difference to the code that uses it -- it's the same
thing.  Not from the compiler's POV of course, but the compiler's job
is to make my life easier.

An access to a scalar is a special case of an access to a general type, 
and of course X is not equivalent to X.all (the equivalence only works
when you're using the object to get somewhere else).

>I guess I was aware of implicit dereferencing. What I didn't appreciate 
>was the value of combining it with formal access-parameters.

Oh, yes indeedy woo.  The day it dawned on me that you could do that was
a good day.  Imagine, if you will, a heterogeneous n-ary tree of tagged
objects with a common ancestor.  Even more specifically, call it an
abstract syntax tree.  The ancestor type might look like this:

   type Abstract_Tree_Node is abstract tagged private;
   procedure Analyse (T : access Abstract_Tree_Node) is abstract;
   procedure Generate_Code (T : access Abstract_Tree_Node) is abstract;
   procedure Execute (T : access Abstract_Tree_Node) is abstract;

   type Abstract_Tree is access all Abstract_Tree_Node'Class;

A statement node could be like this:

   type Statement_Node is abstract new Abstract_Tree_Node with private;
 
   type While_Statement_Node is new Statement_Node with
      record
         Name      : Identifier_Name;
         Condition : Abstract_Tree;
         Loop_Body : Abstract_Tree;
      end record;

   procedure Analyse (T : access While_Statement);
   procedure Generate_Code (T : access While_Statement);
   procedure Execute (T : access While_Statement);
   
The body of the three primitive operations would do some stuff, and make
dispatching calls to Condition and Loop_Body.


   procedure Generate_Code (T : access While_Statement) is
      Label_1, Label_2 : Label;
   begin
      Label_1 := Next_Label;
      Label_2 := Next_Label;

      Generate_Label (Label_1);
      Generate_Code (T.Condition);
      Generate_Branch_On_Zero (Label_2);
      Generate_Code (T.Loop_Body);
      Generate_Branch (Label_1);
      Generate_Label (Label_2);

   end Generate_Code;
 

I've used this sort of thing on, um, about four or five systems, mainly to
test ideas on compilation techniques, and it's not quite as beautiful as it
should be, but it's interesting.  Like anything else, it works well in
general, but the details are what gets you.  I mean, try analysing an
Ada expression using a single Analyse procedure, and without a bunch of
expression-specific abstraction-breaking data shunting.

Now, where's that coffee.

Fraser.
(remove the obvious bits for my real email address)