Modest proposal, 2 of 3

Modest proposal, 2 of 3

[Van Snyder]

BACKGROUND

One of the reasons for code-bloat is the way we teach our children to
structure programs.

What Parnas had in mind when he recommended "information hiding" and
"encapsulation" in Comm. ACM (Dec 72) in "On the criteria for dividing
programs into modules" was that one could thereby (almost) change the
representations of objects in a program by changing their declarations,
but not their references -- no matter what representation one chooses,
the references always look the same: a procedure.

Almost.  In the procedures that support an "abstract data type" one must
still cope with changes in representation.

That's not terrible.  The amount of work necessary to change a
representation is reduced from something proportional to the size of a
program to something on the order of the complexity of the data type.
The unfortunate side effect is that it leads to innumerable tiny
procedures.  On the positive side, the design methodology is applicable
to any language.

Geschke and Mitchell had a better idea in IEEE TSE SE-1, 2 (June 75) in
"On the problem of uniform references to data structures":  Design
languages so that differences in representation are not reflected in
references.  So the [] vs () for arrays vs functions in C would be
considered to be a bad idea.

(Actually, Ross described the germs of the idea in Software Engineering
1 (1969) in "Uniform referents: An essential property for a software
enginering language.")

Minor incremental changes could bring Ada to the state of allowing one
to change the representation of objects without changing their
references.

PROPOSAL for next standardization of Ada

Allow objects to be declared in the public part of a package
specification with mode "out".  The meaning is that clients of the
package can reference the variable, but can't store into it.

Thus, a variable that a package publishes with "out" mode has the same
properties as a private variable with a public parameterless function to
access it, and no procedure to update it directly.  But it's more
efficient, and there's less code to write initially, and therefore less
to read and understand when you're the poor schmo assigned to make the
next minor change.

There's more that could be done to make programs more mutable, less
fragile, and more efficient, all at once.  See "Not so modest proposal,
1 of 1" to be posted soon.
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Modest proposal, 2 of 3

[Robert Dewar]

Van Snyder says

"Thus, a variable that a package publishes with "out" mode has the same
properties as a private variable with a public parameterless function to
access it, and no procedure to update it directly.  But it's more
efficient, and there's less code to write initially, and therefore less
to read and understand when you're the poor schmo assigned to make the
next minor change."


The "more efficient" part of this is completely bogus, since inlining
of the relevant function will eliminate any efficiency overhead.

Personally I do not like the idea of adding out as a keyword to variables,
it would encourage the use of global variables, and global variables are
almost always a bad idea in a language with thread support! I find the
worry about saving a few lines of code here to be a very weak argument.

Re: Modest proposal, 2 of 3

[Norman H. Cohen]

Van Snyder wrote:

> PROPOSAL for next standardization of Ada
> 
> Allow objects to be declared in the public part of a package
> specification with mode "out".  The meaning is that clients of the
> package can reference the variable, but can't store into it.

Somewhat confusing since generic formal parameters of mode IN indicate
that the generic parameter is to be bound to some constant value, and a
subprogram parameter of mode IN is constant within the subprogram body. 
So perhaps instead of

   X: out Integer;

the notation should be

   X: Integer constant when not private;   -- ;-)

> Thus, a variable that a package publishes with "out" mode has the same
> properties as a private variable with a public parameterless function to
> access it, and no procedure to update it directly.  But it's more
> efficient, and there's less code to write initially, and therefore less
> to read and understand when you're the poor schmo assigned to make the
> next minor change.

The effect of an object modifiable as a variable from within a package,
but only readable as a constant from outside the package, can already be
achieved in Ada 95 as follows:

   package P is
      type Access_Constant is access constant Integer;
      Constant_View_Of_Variable: constant Access_Constant;
   private
      Variable: aliased Integer;
      Constant_View_Of_Variable:
         constant Access_Constant := Variable'Access;
   end P;

Of course this doesn't quite achieve the referential transparency Van
Snyder is after, because it requires you to say
Constant_View_Of_Variable.all instead of Constant_View_Of_Variable.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Modest proposal, 2 of 3

[Tucker Taft]

Van Snyder (vsnyder@math.jpl.nasa.gov) wrote:

: ...
: PROPOSAL for next standardization of Ada

: Allow objects to be declared in the public part of a package
: specification with mode "out".  The meaning is that clients of the
: package can reference the variable, but can't store into it.

This can pretty much be accomplished in Ada 95 as follows:

   package P is
       type T is private;
       type T_Reader is access constant T;
       Read_Only_Global : constant T_Reader;
     ...
   private
       Global : aliased T;  -- Global variable
       Read_Only_Global : constant T_Reader := T'Access;
   end P;

You could also create a rename of "Read_Only_Global.all" if need be,
perhaps in a child package.

: ...
: What fraction of Americans believe   |  Van Snyder
: Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Modest proposal, 2 of 3

[Ken Garlington]

Norman H. Cohen wrote:
> 
> The effect of an object modifiable as a variable from within a package,
> but only readable as a constant from outside the package, can already be
> achieved in Ada 95 as follows:
> 
>    package P is
>       type Access_Constant is access constant Integer;
>       Constant_View_Of_Variable: constant Access_Constant;
>    private
>       Variable: aliased Integer;
>       Constant_View_Of_Variable:
>          constant Access_Constant := Variable'Access;
>    end P;
> 
> Of course this doesn't quite achieve the referential transparency Van
> Snyder is after, because it requires you to say
> Constant_View_Of_Variable.all instead of Constant_View_Of_Variable.

Myself, I prefer:

    package P is
      function Constant_View_Of_Variable return Integer;
      pragma Inline (Constant_View_Of_Variable);
    private
      Variable : Integer;
    end P;

    package body P is
      function Constant_View_Of_Variable return Integer is
      begin
        return Variable;
      end Constant_View_Of_Variable;
    end P;

Van Snyder wrote:

>> Thus, a variable that a package publishes with "out" mode has the same
>> properties as a private variable with a public parameterless function to
>> access it, and no procedure to update it directly.  But it's more
>> efficient, 

I write this sort of code all the time, and I promise any reasonable optimizing
compiler will reduce this code to zero overhead, if that's the efficiency in
question.

>> and there's less code to write initially, and therefore less
>> to read and understand when you're the poor schmo assigned to make the
>> next minor change.

"Less code to write" does not necessarily translate into "easier to read and
understand." What you're really trying to do is
separate the client's view of the object's representation from the underlying
implementation. Your specific example involves separating the public view of
a constant integer from the implementation view of a variable integer, or
(to fix the .all problem) an implementation view of access to an integer.
However, a few years down the road, I may just as easily want the public view to
remain a constant integer, and the private view be a variable _fixed-point_ type.
If the "poor schmo" is just using the public view of this object, he doesn't
have to look any further than the spec to understand how to use the object.
So, your proposal isn't helping him. If the "poor schmo" is maintaining the
underlying representation, then your proposal _hurts_ him, since he'll have
to do more work to maintain the public view of constant _integer_ while changing
the underlying type to something else. More importantly, he'll probably end up
changing the public part of the spec, which means every user of this object also
has to change. Now, you've _really_ caused a maintenance problem.

One other comment: What would the proposal mean with respect to accessing
the global "out" variable via child packages? Would private children be
able to write to the variable, for example? It would seem that the rules for
child packages would be further complicated by this proposal.

I think the existing Ada approach is much more flexible than the proposed
solution. If writing these lines is really a burden, then get an editor that
supports templates!

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Modest proposal, 2 of 3

[Richard A. O'Keefe]

>Van Snyder wrote:
> PROPOSAL for next standardization of Ada
> 
> Allow objects to be declared in the public part of a package
> specification with mode "out".  The meaning is that clients of the
> package can reference the variable, but can't store into it.

I note that exporting a function instead has a big advantage:
functions are overloaded, variables aren't.  This is only an
issue to people who use 'use', of course.

I note another benefit of using access functions instead, which
is that if you wonder whether the "variable" actually _is_ being
used outside the package, you can compile for debugging and put
a breakpoint on it, or you can use a profiler like gprof.
A cross-reference would show you _static_ = potential uses only,
a debugger or profiler can show you _actual_ uses.  There's no
reason why profilers _couldn't_ could variable accesses, but none
that I have seen actually does so.

-- 
Fear most of all to be in error.	-- Kierkegaard, quoting Socrates.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.