Re: Parameter Modes, In In Out and Out

[dmitry6243@my-deja.com]

In article <93q6cd$r3k$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93q39q$oq0$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> > In article <93n2co$alq$1@nnrp1.deja.com>,
> >   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > > In article <93modu$36k$1@nnrp1.deja.com>,
> > >   dmitry6243@my-deja.com wrote:

> > > For example, Unix was a very small fraction of the size of
> > > mainframe OS's.
> >
> > That time Unix was considered as a large, ugly, slow and
> > unstable OS compared to RSX-11M.
>
> Well it was not significantly larger, and no one I worked with
> had that viewpoint at all, at least in the commercial world.

The Unix version we had, did not tolerate computer crashes which
sometimes happened several times per day due to hardware problems.
One had a good chance to get the file system totally corrupted,
so we played with Unix a week and after several re-installations,
trowed it out.

> The point is that virtually all serious large scale programming
> (and that is what we are talking about, remember we are talking
> about large programs here if you want to go back and refresh
> your memory :-) was done on mainframes. No companies of any
> significant size depended on PDP-11's for serious work, they
> were restricted to specialized applications like process
> control. For one thing there were no serious operating systems
> with decent file systems, and there was not even a useful COBOL
> compiler. The PDP-11 was definitely NOT a mainstream machine.
>
> The point is that machines in the period you are talking about
> with multiple megabytes of memory were common. Remember the
> name 360 reflects the fact that 360's appeared in 1960 (I am
> guessing you did not program on this machine at this time :-)
> A typical memory for a medium sized machine (360/50) was half
> a megabyte, four times the max memory of the PDP 11.

You might be surprized, but we used PDP-11 for processing air/satelite
images. A standard image was 18Kx18K pixels, so on a 16-bit machine it
was a big fun! The firm had an IBM 370 compatible too, which was used
mostly for calculating and printing salary bills (:-)). The reason why,
is that PDP-11 was outstanding when some non-standard hardware had to
be connected. And all our input and output devices were self-made.

> Now if your emphasis is on *complete* here, i.e. with all the
> details of semantic interactions worked out, then that
> statement makes sense, but we don't need to go there to
> discuss whether MD is useful. Just sketch out what MD would
> mean to you in an Ada environment, and produce an example,
> showing what you would like to be able to write.
--
-- The base type uses some set of distribution functions
-- of the confidence factor. The set is closed for +,-,*,/.
-- The implementation could be potentially very slow.
--
package FuzzyNumbers is
   type FuzzyNumber is tagged private;
   function "+" (Left, Right : FuzzyNumber)
      return FuzzyNumber;
   ...
end FuzzyNumbers;
--
-- A derived type that uses some specialized subset of
-- the distribution functions. It is closed for only
-- +,- but extremely fast. We derive it because we want to
-- mix operands of both types and make some class-wide
-- programming too.
--
package FuzzyNumbers.Special is
   type SpecialFuzzyNumber is new FuzzyNumber with
      null record;
   function "+" (Left, Right : SpecialFuzzyNumber)
      return SpecialFuzzyNumber;
   ...
end FuzzyNumbers.Special;
--
-- So far it is Ada 95. Let we make a fuzzy neuro network
-- to fake our innoncent customers (:-)). We implement
-- nodes of the network. Each node has a procedure
-- calculating the output:
--
with FuzzyNumbers; use FuzzyNumbers;
package Network is
   type Node is tagged private;
   type Link is access Node;
   function Compute
            (  X      : Node;
               Input1 : FuzzyNumber'Class;
               Input2 : FuzzyNumber'Class
            )  return FuzzyNumber'Class;
   ...
end Network;
--
-- Summator is an instance of a node:
--
package Network.Summators is
   type Summator is new Node with null record;
   function Compute
            (  X      : Summator;
               Input1 : FuzzyNumber'Class;
               Input2 : FuzzyNumber'Class
            )  return FuzzyNumber'Class;
   ...
end Network.Summators;
--
-- Now a naive implementation of the summator
-- node:
--
package body Network.Summators is
   function Compute
            (  X      : Summator;
               Input1 : FuzzyNumber'Class;
               Input2 : FuzzyNumber'Class
            )  return FuzzyNumber'Class is
   begin
      return Input1 + Input2; -- Opps!
   end Compute;
end Network.Summators;
--
-- This implementation will time to time entertain us with
-- Constraint_Error. The problem is that the developer
-- expected here a triple dispatch to + involving the result,
-- the left and the right operands. The specification
-- of FuzzyNumbers.Special leaves most of the combinations
-- FuzzyNumber, SpecialFuzzyNumbers undefined (Ada 95 does
-- not have MD). An MD aware compiler could say for
-- the specification of FuzzyNumber.Special:

"Error! All signatures have to be overriden", I.e. not only

function "+" (Left, Right : SpecialFuzzyNumber)
   return SpecialFuzzyNumber;

but also:

function "+" (Left : FuzzyNumber; Right : SpecialFuzzyNumber)
   return FuzzyNumber;
function "+" (Left : SpecialFuzzyNumber; Right: FuzzyNumber)
   return FuzzyNumber;
function "+" (Left, Right : FuzzyNumber)
   return FuzzySpecialNumber;
function "+" (Left : FuzzyNumber; Right : SpecialFuzzyNumber)
   return SpecialFuzzyNumber;
function "+" (Left : SpecialFuzzyNumber; Right: FuzzyNumber)
   return SpecialFuzzyNumber;
function "+" (Left, Right : SpecialFuzzyNumber)
   return FuzzyNumber;

This would fill all the slots of the 3D dispatch table. Some
syntax should be provided to inherit a combination from the
ancestors.

for
   function "+" (Left : FuzzyNumber; Right : SpecialFuzzyNumber)
      return SpecialFuzzyNumber
use
   function "+" (Left : FuzzyNumber; Right : FuzzyNumber)
      return FuzzyNumber;

seems too heavy weighted and directly refers to the parent
type, which is bad. (I have no idea).

> Surely overloading was familiar from Algol 68?

Theoretically maybe, but practically I never saw an Algol 68 compiler.
Even Algol 60 was hard to get. Our OS 360 variant required to put
all kewords in '' quotes (i.e. 'begin' instead of begin)! (:-)).
In contrary to this PL/1 had an optimized compiler and an interactive
debugger (which were a bit incompatible (:-))

[ MI issue I leave for later ]

--
Regards,
Dmitry Kazakov


Sent via Deja.com
http://www.deja.com/