Parameter Modes, In In Out and Out

Parameter Modes, In In Out and Out

[i.a.mcleod]

What is the difference between In Out and Out parameters according to the
way compilers handle these.  I can't see any difference.  An out parameter
is still taken in.  I am confused by this anyone help?

Re: Parameter Modes, In In Out and Out

[tmoran]

> An out parameter is still taken in.
    No, actually, it is not.  The formal parameter should be treated
as an uninitialized variable.  (You can get into some flaky situations
if the parameter is passed by reference - a large array, say - but
your program should not rely on such things.)

Re: Parameter Modes, In In Out and Out

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

"i.a.mcleod" <i.a.mcleod@ntlworld.com> a �crit dans le message news: Zmt56.57012$ca6.937797@news6-win.server.ntlworld.com...
> What is the difference between In Out and Out parameters according to the
> way compilers handle these.  I can't see any difference.  An out parameter
> is still taken in.  I am confused by this anyone help?
>
There is a huge difference. Consider:

procedure P (X : out Some_Type);

By looking at the specification (NOT the body), I can tell that the procedure cannot rely on the previous value of the parameter,
and therefore that it is safe to call it to initialize an unitialized variable, whose value can be invalid. I could not assume this
with an in out parameter.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <7Cx56.90736$A06.3322588@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> > An out parameter is still taken in.
>     No, actually, it is not.

This is false information. In many instances, outlined clearly
in the RM, the questioner is right, an IN OUT parameter and
an OUT parameter are identical.

Yes, from a conceptual documentation point of view, if you
use OUT, then you should not read the parameter, but the RM
is quite clear that this in many cases this is just a
documentation convention and nothing more.

This is true for all by-reference types, and in particular, for
all tagged types OUT is exactly the same as IN OUT
semantically.


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

Re: Parameter Modes, In In Out and Out

[tmoran]

>>> An out parameter is still taken in.
>>     No, actually, it is not.
>This is false information.
  Robert is technically correct about that sentence.  As noted in the
unquoted part of my post, by-reference is an exception.  Ada is a
language meant to be read by humans, not just compilers, however.
Though it may be obvious to a compiler, or a compiler writer, that a
particular OUT parameter can be treated as IN OUT, it may be
confusing to a human reader, and thus should not be done.

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <UFK56.92519$A06.3377688@news1.frmt1.sfba.home.com>,
  tmoran@acm.org wrote:
> >>> An out parameter is still taken in.
> >>     No, actually, it is not.
> >This is false information.
>   Robert is technically correct about that sentence.  As
noted in the
> unquoted part of my post, by-reference is an exception.  Ada
is a
> language meant to be read by humans, not just compilers,
however.
> Though it may be obvious to a compiler, or a compiler writer,
that a
> particular OUT parameter can be treated as IN OUT, it may be
> confusing to a human reader, and thus should not be done.


This is quite a confusing followup. A by-reference type is NOT
the same thing as a parameter that happens to be passed by
reference (Tom mentioned large arrays, but that has nothing
whatever to do with by-reference types).

A by-reference type is one that is *REQUIRED* to be passed
by reference. A program may definitely RELY on such a parameter
being passed by reference, and it is not flaky, or undesirable,
or bad practice, to rely on this, since it is guaranteed by the
language.

For such types, IN OUT is identical to OUT semantically (this
is NOT the case with large arrays that happen to be passed by
reference).

Tom in his earlier post said

 >>> An out parameter is still taken in.
> >>     No, actually, it is not.

And it is the reply here that I was saying is quite wrong. The
out parameter *IS* "taken in" for a by-reference type and there
is nothing wrong with relying on this (in fact it is quite
common to read at least some part of out parameters, e.g. array
bounds, and this was allowed even in Ada 83).

So this is not a matter of being technically correct, it is an
important part of the language semantics, and should be
properly understood!

Yes, purely as a stylistic matter one may prefer to use OUT to
indicate that the program does not read anything important from
the parameter, where anything important is not necessarily well
defined (for example, it is perfectly normal for a program to
access the tag of an OUT parameter -- and yes, I know, the tag
is not part of the value :-). But that's all this is, a purely
stylistic issue.

In other situations with by-copy types that are not access
types, it is plain wrong (a bounded error) to read an OUT
parameter, so it is really important to understand the
distinction here, and not sweep it under the carpet of
stylistic rules :-)


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

Re: Parameter Modes, In In Out and Out

[John English]

Robert Dewar wrote:
> 
> In article <7Cx56.90736$A06.3322588@news1.frmt1.sfba.home.com>,
>   tmoran@acm.org wrote:
> > > An out parameter is still taken in.
> >     No, actually, it is not.
> 
> This is false information. In many instances, outlined clearly
> in the RM, the questioner is right, an IN OUT parameter and
> an OUT parameter are identical.

Ouch. The implication of this statement, read loosely, is that "out"
parameters are redundant and can be replaced by "in out" parameters.
It may be strictly false information, but I think it's more confusing
to assert that "out" means the same as "in out" (since many readers will
forget to factor in the leading "in many instances" and will get lost in
a maze of twisty little grammar rules, all alike).

I prefer to consider parameter passing by copy-and-return rather than
by-reference as the norm (even though it applies to fewer situations
in practice): "out" parameters are initially uninitialised (if that
makes sense to you ;-) and the final value is copied out on return
from the procedure, whereas "in out" parameters are copied in on entry
and so are guaranteed to have valid initial values.

Side effects due to aliasing complicate this (you then have to know
which
types are passed by reference and which aren't) but I think that
assuming
by-reference parameter passing as the default makes understanding what's
going on (as in this question of "out" vs. "in out") more complicated,
not
less; in the absence of side effects, copy-in-and-out is equivalent to
by-reference and distingusiahes clearly between the various cases. And
anyone who uses aliasing for side effects deserves to sow what they
reap,
IMHO... ;-)

YMMV, especially if your name is "Robert"; language lawyers and language
users are different audiences for such debates IMHO ;-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <3A57CD7F.2228BFD5@brighton.ac.uk>,
  John English <je@brighton.ac.uk> wrote:

> I prefer to consider parameter passing by copy-and-return
> rather than by-reference as the norm (even though it applies
> to fewer situations in practice)

But unfortunately, this model is just wrong for by-reference
types. Especially in object oriented programming, where all
tagged types are passed by reference, it is quite wrong to
regard the input as uninitialized, since this does not
correspond with the semantics of the language.

For example, one can imagine a situation in which some field
of an object serves merely as a kind of logical "tag", and it
makes sense to read it, just as it makes sense to read the real
tag, and bounds information. You might decide that logically it
is reasonable to consider a parameter to be be an OUT parameter
if the routine only reads this logical tag field, but
initializes all the other fields.

The treatment in Ada 95 is different from Ada 83 in this area,
you need to readjust thinking a bit :-)


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

Re: Parameter Modes, In In Out and Out

[DuckE]

"i.a.mcleod" <i.a.mcleod@ntlworld.com> wrote in message
news:Zmt56.57012$ca6.937797@news6-win.server.ntlworld.com...
> What is the difference between In Out and Out parameters according to the
> way compilers handle these.  I can't see any difference.  An out parameter
> is still taken in.  I am confused by this anyone help?
>
>

I'm not sure whether all compilers handle this the same, but with the
compiler I use most frequently:

A parameter that is passed as an "In Out" will have a constraint check on
entry to the procedure and a parameter passed as "Out" will not.

This became obvious to me when translating Pascal code to Ada 95.  In Pascal
it is common to pass an uninitialized variable as a "VAR" parameter to a
procedure.  In Pascal this did not result in an exception.  Using an Ada "In
Out" sometimes causes a constraint error exception and using Adas' "Out"
does not.


SteveD

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <938p3u$omv$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <3A57CD7F.2228BFD5@brighton.ac.uk>,
>   John English <je@brighton.ac.uk> wrote:
>
> > I prefer to consider parameter passing by copy-and-return
> > rather than by-reference as the norm (even though it applies
> > to fewer situations in practice)
>
> But unfortunately, this model is just wrong for by-reference
> types. Especially in object oriented programming, where all
> tagged types are passed by reference, it is quite wrong to
> regard the input as uninitialized, since this does not
> correspond with the semantics of the language.

OOP does not enforce "tagged types" to be passed by reference. This is
Ada 95 specific. Only class-wide types shall be passed by reference (for
their size is unknown).

Maybe I am wrong, but it seems that RM does not forbid to keep the type
tag separated from the value. Does it?

Anyway the clear distinction of normal types and class-wide types is an
excellent (revolutionaly, IMO) concept. It is pity that Ada 95 didn't
use all advantages of the concept. For instance, to have multiple
dispatch, or even, all types "tagged"!

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93cagm$c1j$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:

> OOP does not enforce "tagged types" to be passed by
> reference. This is
> Ada 95 specific. Only class-wide types shall be passed by
> reference (for their size is unknown).
>
> Maybe I am wrong

Well I am not quite sure what you are saying here, but most
cerainly ALL tagged types must be passed by reference:

RM 6.2 (4)


4   A type is a by-reference type if it is a descendant of one
of the
following:

    5  a tagged type;

    6  a task or protected type;

    7  a nonprivate type with the reserved word limited in its
       declaration;

    8  a composite type with a subcomponent of a by-reference
                                            type;

    9  a private type whose full type is a by-reference type.

That's pretty clear. By the way it is *easy* to answer
questions like this for yourself from the RM. What I did to
locate this section was to open my trusty ascii only version of
the RM in my editor and search for by-reference -- not so
difficult.

The mention you make of keeping the tag separate from the value
is entirely irrelevant here.


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93cagm$c1j$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> It is pity that Ada 95 didn't
> use all advantages of the concept. For instance, to have
> multiple dispatch, or even, all types "tagged"!

It is NOT "using all advantages of [a] concept" to insist that
it be used absolutely everywhere. On the contrary, that kind of
approach leads to a much more restrictive and less useful
expressive power.

As for multiple dispatch -- people can disagree -- but I think
the designers of Ada 95 were pretty much unanimous in rejecting
consideration of MD -- it's far too much complexity for far too
little gain. (please note, MD /= Multiple Inheritance -- the
two concepts are unrelated).


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93e4e6$ucg$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93cagm$c1j$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> > It is pity that Ada 95 didn't
> > use all advantages of the concept. For instance, to have
> > multiple dispatch, or even, all types "tagged"!
>
> It is NOT "using all advantages of [a] concept" to insist that
> it be used absolutely everywhere. On the contrary, that kind of
> approach leads to a much more restrictive and less useful
> expressive power.

If you meant under the concept "to be used everywhere" the type based
distinction between things that dispatch and things that do not",
then I do insist (:-). Do you disagree?

If the concept is an ability to derive from a type, then please note
that already in Ada 83, one had an ability to derive from any type:

type XX is new X;

How could this be "restrictive"?

> As for multiple dispatch -- people can disagree -- but I think
> the designers of Ada 95 were pretty much unanimous in rejecting
> consideration of MD -- it's far too much complexity for far too
> little gain. (please note, MD /= Multiple Inheritance -- the
> two concepts are unrelated).

Yes "people" disagree (:-). IMO both MD and MI are a rigid must,
just because they are closures of the concepts of having a dispatching
parameter and of having a base type.

Single dispatch is like to have overloading involving exactly one
dedicated parameter. I am well aware of artefacts of MD. Nobody says
that MD is simple. But single dispatch is simply wrong for binary
operations. (Nice that Ada at least enforces same tag for all
dispatching parameters. In C++ the situaltion is catastrophic). It
is better not to use a thing at all than to use it incorrectly.

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93e498$ua1$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93cagm$c1j$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
>
> > OOP does not enforce "tagged types" to be passed by
> > reference. This is
> > Ada 95 specific. Only class-wide types shall be passed by
> > reference (for their size is unknown).
> >
> > Maybe I am wrong
>
> Well I am not quite sure what you are saying here, but most
> cerainly ALL tagged types must be passed by reference:

[...]

Yes this is what I meant under Ada specific. I.e. "must" means,
"RM says so". Or in the most short form OOP /= RM (:-)

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93encq$brm$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> But single dispatch is simply wrong for binary
> operations.

Declaring something is "simply wrong" is not an argument, just
an unsubstantiated claim. The issue here is one of complexity
versus functinality. The issue has been argued in great detail
on previous occasions, so there is little point in arguing
again, unless you think you have a new argument to bring to
the table (of which I have seen no evidence so far). I would
recommend that you dig up and study previous discussions of
this topic, and the open it again only if you think you have
something really new to add.

Otherwise I assume the conclusion will be the same as in
previous discussions :-)


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

Re: Parameter Modes, In In Out and Out

[Thierry Lelegard]

> procedure P (X : out Some_Type);
> 
> By looking at the specification (NOT the body), I can tell that the
> procedure cannot rely on the previous value of the parameter,
> and therefore that it is safe to call it to initialize an
> unitialized variable, whose value can be invalid. I could not assume this
> with an in out parameter.

This is quite true, especially with floating point types for which
some binary patterns are NaN (Not a Number), ie. invalid values.
On some architectures (I remember the old time of the VAX),
passing an uninitialized variable as "in out" may raise an
exception _even_if_the_procedure_never_reads_the_input_value_.
The by-copy semantic generates a MOVF ("move F_float") instruction
for "in" and this instruction generates a trap if the binary pattern
is an invalid floating point value.

So, Jean-Pierre Rosen is right, never use "in out" for "out" when you
cannot be sure that the actual parameter is properly initialized.

____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75516 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93f6ar$m44$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93encq$brm$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> > But single dispatch is simply wrong for binary
> > operations.
>
> Declaring something is "simply wrong" is not an argument, just
> an unsubstantiated claim. The issue here is one of complexity
> versus functinality. The issue has been argued in great detail
> on previous occasions, so there is little point in arguing
> again, unless you think you have a new argument to bring to
> the table (of which I have seen no evidence so far). I would
> recommend that you dig up and study previous discussions of
> this topic, and the open it again only if you think you have
> something really new to add.

It is not complex vs. functional, it is correct vs. incorrect. Single
dispatch is NOT applicable for types having binary operations as
methods. It was discussed in comp.object. Ada's way to "handle" this
problem is to force type tags of dispatching parameters be same. This
is unsafe, because it happens in worst case at run-time.

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93flab$2mh$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:

> It is not complex vs. functional, it is correct vs.
> incorrect.

I think there may be a language problem here :-)

We are looking for technical arguments which always have to
balance complexity against functinlaity (remember that we can
do anything with Turing machines, but it is inconvenient and
inefficient, so in some sense what languages are all about is
addressing these problems of convenience and efficiency without
introducing too much complexity).

Saying something is incorrect is NOT an argument.

You might as well say that any language that does no provide
complete referential transparency is incorrect. Yes, in the
environment in which this discussion takes place, that is true,
but it does not mean we have to immediately go and implement
lazy evaluation in Ada 95 :-)


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

Re: Parameter Modes, In In Out and Out

[Laurent Guerby]

"i.a.mcleod" <i.a.mcleod@ntlworld.com> writes:
> What is the difference between In Out and Out parameters according
> to the way compilers handle these.  I can't see any difference.  An
> out parameter is still taken in.  I am confused by this anyone help?

To add some code to the discussion, here is a case where changing
"out" into "in out" changes the behaviour of a program from perfectly
ok to erroneous:

procedure T is
   Magic : constant := 12345;

   X : Integer := Magic;

   procedure P (Y : in out Integer) is
   begin
      null;
   end P;

begin
   P (X);
   if X /= Magic then
      raise Program_Error;
   end if;
end T;

If you compile and run T, you'll get no output as expected. Now if you
change the mode of Y to "out", if your compiler uses by copy passing
for integer, you'll probably get a program_error, because the
generated code for exiting P will set X with an unitialized stack
value (the place reserved for the Y value).

It is interesting to see that the P call "undo" the X initialization.
So if you have a coding standard that says that all "variables" must
be initialized, it's not enough in Ada, you also need to initialize
all "out parameters of type not determined to be by-reference" to be
safe from the unitialized variable syndrome in Ada.

PS: this is not theory, I just saw (and fixed) an instance of this
problem at work today (just with code a bit more convoluted ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: Parameter Modes, In In Out and Out

[Florian Weimer]

Laurent Guerby <guerby@acm.org> writes:

> if your compiler uses by copy passing for integer,

Scalar types are elmentary types and are therefore passed by copy.

> you'll probably get a program_error, because the generated code for
> exiting P will set X with an unitialized stack value (the place
> reserved for the Y value).

Or a Constraint_Error, or a Program_Error raised explicitly by your
code, or nothing.  

Speaking of out-mode pass-by-copy parameters, I've encountered another
odd thing.  Given the following code:

     procedure Do_Something_With (X : Integer);

     procedure Foo (X : out Integer) is
     begin
        raise Constraint_Error;
     end Foo;
           
     declare
        Y : Integer := 0;
     begin
        begin
           Foo (Y);
        exception
           when Constraint_Error =>
              null;
        end;
       
        Do_Something_With (Y);
     end;

Is it guaranteed by the language that Y is 0 when Do_Something_With is
called?  (Or, put the other way round, can a compiler perform
dead-store elimination in this context?)

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Tue, 9 Jan 2001, Robert Dewar wrote:
> In article <93flab$2mh$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> 
> > It is not complex vs. functional, it is correct vs.
> > incorrect.
> 
> I think there may be a language problem here :-)
> 
> We are looking for technical arguments which always have to
> balance complexity against functinlaity

As much as I like multimethods, I have to agree that for a language like 
Ada, which is a relatively low level language which should be efficiently 
implementable without heroics, MM are probably too much to ask for. I'd
like full closures too but that ain't happenin' without GC!

[...snip...]

> You might as well say that any language that does no provide
> complete referential transparency is incorrect. Yes, in the
> environment in which this discussion takes place, that is true,
> but it does not mean we have to immediately go and implement
> lazy evaluation in Ada 95 :-)

Explain please. There are languages which are referentially transparent 
which are also strict/eager. Mercury and Opal come to mind (see, I can
play the obscure language game as well as anyone :).

-- Brian

PS: Mercury seems to be a very worthy successor to Prolog.

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93fqau$6m2$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93flab$2mh$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
>
> > It is not complex vs. functional, it is correct vs.
> > incorrect.
>
> I think there may be a language problem here :-)
>
> We are looking for technical arguments which always have to
> balance complexity against functinlaity (remember that we can
> do anything with Turing machines, but it is inconvenient and
> inefficient, so in some sense what languages are all about is
> addressing these problems of convenience and efficiency without
> introducing too much complexity).
>
> Saying something is incorrect is NOT an argument.

Surely. Any program is incorrect in some sense.

But neither an argument is a reference to some mystic balance between
such fluid factors that complexity, functionality and the problems the
programs have to solve. It is not very long time ago when a program of
1Mb size was something unimaginable. Now it is hard to produce one
of less size (in conventional environment).

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93h9mo$bbm$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> But neither an argument is a reference to some mystic balance
> between such fluid factors that complexity, functionality and
> the problems the programs have to solve.

> It is not very long time ago when a program of
> 1Mb size was something unimaginable.

Well, quite a long time ago, certainly you have to go back
over 30 years, which in the world of computers is a VERY
long time.

> Now it is hard to produce one
> of less size (in conventional environment).

That's a very peculiar statement, very few of the programs
I write are anywhere near a megabyte long.

Not that either of these points has any detectable relevance
to multiple dispatching mind you!


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article
<Pine.BSF.4.21.0101091641170.3696-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:

> Explain please. There are languages which are referentially
> transparent  which are also strict/eager. Mercury and Opal
> come to mind (see, I can play the obscure language game as
> well as anyone :).

I use the term RT in the sense that Miranda uses it (i.e. the
way Dave Turner would use it), and in that sense, it implies
laziness.

For example, if I have a projection function

  x (a,b) = b

then I must be able to replace x(b) with x(a,b) for any
possible a, and that includes computations which if done
eagerly would cause an infinite recursion.

It's just a matter of use of words, so just understand that
when I used RT as a term, I was using it in this sense. I can
guess at the way you use the term from your examples, and
that's just fine, but rather irrelevant to the discussion at
hand.


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93f9pi$uaa$1@s1.read.news.oleane.net>,
  "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> wrote:

> So, Jean-Pierre Rosen is right, never use "in out" for "out"
> when you cannot be sure that the actual parameter is properly
> initialized.

Just to once again clarify. There are two cases here

1. The parameter is a by-copy type (or a type that can
optionally be passed by copy). In this case, the advice
above corresponds to advice to avoid definite (or potential)
bounded errors. Important indeed! Note that the implementation
which raised an error was not only correct, but friendly, since
it is friendly for implementations to detect bounded errors.

2. The parameter is a by-reference type, in this case the
above advice is just a matter of stylistic considerations.


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <86itno316m.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:

> if your compiler uses by copy passing
> for integer, you'll probably get a program_error, because the
> generated code for exiting P will set X with an unitialized
> stack value (the place reserved for the Y value).

All compilers MUST pass integers by copy, there is no choice.



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

Re: Parameter Modes, In In Out and Out

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <86itno316m.fsf@acm.org>,
>   Laurent Guerby <guerby@acm.org> wrote:
> 
> > if your compiler uses by copy passing
> > for integer, you'll probably get a program_error, because the
> > generated code for exiting P will set X with an unitialized
> > stack value (the place reserved for the Y value).
> 
> All compilers MUST pass integers by copy, there is no choice.

Unless you can prove that passing them by reference would be equivalent,
of course.  E.g., for [in] out parameters, we generally pass an address
of something.  Usually that something is a temp which is initialized
by copy from the actual parameter.  However, if we can prove that
it is safe to pass the address of the actual parameter itself
(which involves checking for the presence of things like exception
handlers, local task units, aliasing, etc.) then we can do so,
and thereby avoid the space and copy [in/]out for the temp.

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA  USA
(AverCom was formed 1/1/01 from the Commercial Division of AverStar)
(http://www.averstar.com/services/ebusiness_applications.html)

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <3A5CF57A.225BC5B5@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> Unless you can prove that passing them by reference would be
> equivalent, of course.

Well when we say that something must be passed by copy, we are
not making statements about generated code, but about
semantics. After all the compiler can do anything it likes
if it makes no difference. For example, if it knows that the
result of a call to the cosine function is not needed, then the
compiler can call the sine function instead, but that's not
really relevant in talking about semantics.




  E.g., for [in] out parameters, we generally pass an address
> of something.  Usually that something is a temp which is
initialized
> by copy from the actual parameter.  However, if we can prove
that
> it is safe to pass the address of the actual parameter itself
> (which involves checking for the presence of things like
exception
> handlers, local task units, aliasing, etc.) then we can do
so,
> and thereby avoid the space and copy [in/]out for the temp.
>
> --
> -Tucker Taft   stt@avercom.net
http://www.averstar.com/~stt/
> Chief Technology Officer, AverCom, Inc. (A Titan Company)
Burlington, MA  USA
> (AverCom was formed 1/1/01 from the Commercial Division of
AverStar)
>
(http://www.averstar.com/services/ebusiness_applications.html)
>


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93il87$iqo$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93h9mo$bbm$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> > But neither an argument is a reference to some mystic balance
> > between such fluid factors that complexity, functionality and
> > the problems the programs have to solve.
>
> > It is not very long time ago when a program of
> > 1Mb size was something unimaginable.
>
> Well, quite a long time ago, certainly you have to go back
> over 30 years, which in the world of computers is a VERY
> long time.

I would say 15 years. That time PDP-11 with 256K was a quite common
model. The process address space was 64K. A "very large" program was
FORTRAN-IV compiler (30-40K).

> > Now it is hard to produce one
> > of less size (in conventional environment).
>
> That's a very peculiar statement, very few of the programs
> I write are anywhere near a megabyte long.

A couple of windows here, pair ActiveX controls there, plus misuse of
STL and here you are.

> Not that either of these points has any detectable relevance
> to multiple dispatching mind you!

The point was that among all arguments pro and cotra including some
feature into a universal and long living system, a reference to balance
between complexity and functionality is the weakest one. Please note
the words "universal" and "long living".

IMO the first role should play such factors regularity, correctness and
volume.

Anyway, let's see what will happen with MD in the static typed languages
in the next 5-10 years.

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93k6dv$qt6$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93il87$iqo$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <93h9mo$bbm$1@nnrp1.deja.com>,
> > > It is not very long time ago when a program of
> > > 1Mb size was something unimaginable.
> >
> > Well, quite a long time ago, certainly you have to go back
> > over 30 years, which in the world of computers is a VERY
> > long time.
>
> I would say 15 years. That time PDP-11 with 256K was a quite
> common model. The process address space was 64K. A "very
> large" program was FORTRAN-IV compiler (30-40K).

That was a "mini-computer", so called because it was tiny
compared to main-frames. You cannot judge typical large
application program size by looking at mini-computers of
the time. The 64K memory seemed absurdly small by mainframe
standards (it was already common to see multiple megabytes of
physical memory on mainframes at that time). So looking at
program size on PDP-11's as a guide for typical program size
is like looking at the Palm Pilot today to get an idea of
typical program size today (on the Palm Pilot, applications
larger than 100K are unusual, and indeed my brother's datebk4
program, at about 450K is the largest application program in
common use on that platform :-)

> > > Now it is hard to produce one
> > > of less size (in conventional environment).
> >
> > That's a very peculiar statement, very few of the programs
> > I write are anywhere near a megabyte long.
>
> A couple of windows here, pair ActiveX controls there, plus
> misuse of STL and here you are.

Misuse will get you anywhere :-)

> The point was that among all arguments pro and cotra
> including some feature into a universal and long living
> system, a reference to balance between complexity and
> functionality is the weakest one. Please note the words
> "universal" and "long living".

Sounds like you have not had much experience in the real world
of language design, where this balance is THE primary issue in
design considerations.

> IMO the first role should play such factors regularity,
> correctness and volume.

Sorry, that sentence is too garbled, I have no idea what
"volume" refers to in the context of language design.
Regularity (often referred to as orthogonality) is indeed
a critical feature, and actually this is where it is very
difficult to get a clear definition of MD (or MI for that
matter :-)

Correctness is an odd concept in the language design
environnment, unless you mean that something is correct if
dmitry declares it correct (an approach you seem to have taken
in the past). If you mean consistency in a formal sense, yes,
then of course this is a necessary (but not sufficient)
condition.

Language design is much harder than people think. Well meaning
technical folks with a little bit of experience in language
semantics, but no experience in full language design, often
vastly underestimate the difficulties involved. Dmitry, if you
want to follow and understand some of the language design
issues involved in Ada 95, I would go read the archives, and in
particular, read the sequence of mapping documents.

> Anyway, let's see what will happen with MD in the static
> typed languages in the next 5-10 years.

My guess: nothing much. I just don't see any constituency that
would push in favor of moving in this direction for statically
typed languages. The arguments are quite weak (note that Dmitry
has not been able to present any specific arguments, beyond the
claim that binary operators require MD, but with no good
examples).

In practice in Ada, you can always achieve the effects of MD
in specific instances, and the generalization is just not worth
the effort, given how rarely it would be of use.


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

Re: Parameter Modes, In In Out and Out

[Laurent Guerby]

Robert Dewar <robert_dewar@my-deja.com> writes:
> Laurent Guerby <guerby@acm.org> wrote:
> > if your compiler uses by copy passing
> > for integer, you'll probably get a program_error, because the
> > generated code for exiting P will set X with an unitialized
> > stack value (the place reserved for the Y value).
> 
> All compilers MUST pass integers by copy, there is no choice.

Yes (unless an appropriate pragma is used to overide the mandated Ada
passing convention). My wording was sloppy, I meant to talk at the
generated code level, not at the Ada copy out semantic here.

The idea is that for my example code, the compiler could have done
many things, and you'll get the user program_error if and only if the
compiler did copy out the parameter at the code level. Other valid
behaviours are (I believe) to remove the call, not to copy out,
friendly raise some exception at procedure exit, etc... (hence the
"probably").

-- 
Laurent Guerby <guerby@acm.org>

Re: Parameter Modes, In In Out and Out

[Thierry Lelegard]

> > > That's a very peculiar statement, very few of the programs
> > > I write are anywhere near a megabyte long.
> >
> > A couple of windows here, pair ActiveX controls there, plus
> > misuse of STL and here you are.
> 
> Misuse will get you anywhere :-)

with Ada.Text_IO;
procedure Hello is
begin
    Ada.Text_IO.Put_Line ("Hello");
end Hello;

is 271 KB big with GNAT on Solaris.

A demo TCP server (simple echo server) is 3 MB big.

Real misuse indeed ;-))

____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75516 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: Parameter Modes, In In Out and Out

[Pascal Obry]

"Thierry Lelegard" <thierry.lelegard@canal-plus.fr> writes:

> with Ada.Text_IO;
> procedure Hello is
> begin
>     Ada.Text_IO.Put_Line ("Hello");
> end Hello;
> 
> is 271 KB big with GNAT on Solaris.

I have this same program compiled under Windows NT and its size is 185kb or
60kb (as you like :) depending of the compilation options... And what ? We
have already debated (many time) about the Ada executable size and found just
nothing interesting...

> 
> A demo TCP server (simple echo server) is 3 MB big.

I have a full (rather big) GLADE client/server applications under Windows NT
and the server is around 1Mb. Clients (20 of them) ranging from 150kb to
700kb. Your 3Mb seems a bit large to me for a simple echo server ?????

> 
> Real misuse indeed ;-))

Indeed :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93cagm$c1j$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <938p3u$omv$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <3A57CD7F.2228BFD5@brighton.ac.uk>,
> >   John English <je@brighton.ac.uk> wrote:
> >
> > > I prefer to consider parameter passing by copy-and-return
> > > rather than by-reference as the norm (even though it applies
> > > to fewer situations in practice)
> >
> > But unfortunately, this model is just wrong for by-reference
> > types. Especially in object oriented programming, where all
> > tagged types are passed by reference, it is quite wrong to
> > regard the input as uninitialized, since this does not
> > correspond with the semantics of the language.
>
> OOP does not enforce "tagged types" to be passed by reference. This is
> Ada 95 specific. Only class-wide types shall be passed by reference
(for
> their size is unknown).

"tagged type" is an Ada locution -- when Robert uses it, you know he is
talking about Ada!  So I think he meant something like, "...in object
oriented Ada programming where you are using tagged types, it is quite
wrong to regard the parameter as uninitialized, since tagged types are
always passed by reference"!

>
> Maybe I am wrong, but it seems that RM does not forbid to keep the
type
> tag separated from the value. Does it?

No, it doesn't; it's just that the tag is not "part of" the value
(regardless of where it is "kept").

>
> Anyway the clear distinction of normal types and class-wide types is
an
> excellent (revolutionaly, IMO) concept. It is pity that Ada 95 didn't
> use all advantages of the concept. For instance, to have multiple
> dispatch, or even, all types "tagged"!

Interesting idea, but I don't know that I agree it's "a pity" that Ada
didn't do these things.  Ada is a practical language.  Making scalars,
etc. carry a tag around wouldn't be worth it.  It would really foul up
system-level programming and interfacing to other languages. I don't
see a whole lot of value in doing classwide programming on integers or
arrays anyway (with plenty of opportunity for obscure code).  Can't you
get the same effect by declaring a tagged container, then deriving from
that?  Use a tagged record if you want taggedness... simple, there's no
loss of power there...

-- mark



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

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93e4e6$ucg$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
>
> It is NOT "using all advantages of [a] concept" to insist that
> it be used absolutely everywhere. On the contrary, that kind of
> approach leads to a much more restrictive and less useful
> expressive power.
>

Very true.

My favorite example is the notion of "purity" of OO languages, which
holds that some good comes from the ability to say "everything is a
class".  The only result is that you have to contort everything into
_being_ a class for the sake of being able to say this, so for instance
you have to have a "singleton" design pattern to work around not having
packages with state, etc.

-- mark


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

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93encq$brm$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93e4e6$ucg$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:

> > As for multiple dispatch -- people can disagree -- but I think
> > the designers of Ada 95 were pretty much unanimous in rejecting
> > consideration of MD -- it's far too much complexity for far too
> > little gain. (please note, MD /= Multiple Inheritance -- the
> > two concepts are unrelated).
>
> Yes "people" disagree (:-). IMO both MD and MI are a rigid must,
> just because they are closures of the concepts of having a dispatching
> parameter and of having a base type.

How does being the "closure" of a concept in the language make it
a "rigid must"?

The point of a programming language is to solve programming problems,
right?  In the case of MI, for instance, Ada shows that in fact it is
_not_ a "must"!  Composition can be made sufficiently powerful (with
access discriminants) to solve the pogramming problem in this case, so
it's hard to argue that MI is a must-have, other than on purely
theoretical grounds.

-- mark


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

Re: Parameter Modes, In In Out and Out

[John English]

mark_lundquist@my-deja.com wrote:
> In article <93encq$brm$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:
> > IMO both MD and MI are a rigid must,
> > just because they are closures of the concepts of having a dispatching
> > parameter and of having a base type.
> 
> How does being the "closure" of a concept in the language make it
> a "rigid must"?

Indeed. Java has to be rejected (no MI); presumably C# too (I read
the docs once, then couldn't find them again despite mighty searches
of the MS website, but the impression was "oh, just like Java" :-);
C++ squeaks(*) in with MI but no MD; that leaves... hmmm... CLOS sounds
a bit like "closures", don't you think? ;-)

(*) Ceci n'est pas un Smalltalk.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Parameter Modes, In In Out and Out

[Florian Weimer]

Pascal Obry <p.obry@wanadoo.fr> writes:

> > A demo TCP server (simple echo server) is 3 MB big.
> 
> I have a full (rather big) GLADE client/server applications under Windows NT
> and the server is around 1Mb. Clients (20 of them) ranging from 150kb to
> 700kb. Your 3Mb seems a bit large to me for a simple echo server ?????

The size is probably due to a statically linked copy the FLORIST
library (perhaps with debugging information).

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93ko49$auq$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> That was a "mini-computer", so called because it was tiny
> compared to main-frames. You cannot judge typical large
> application program size by looking at mini-computers of
> the time. The 64K memory seemed absurdly small by mainframe
> standards (it was already common to see multiple megabytes of
> physical memory on mainframes at that time). So looking at
> program size on PDP-11's as a guide for typical program size
> is like looking at the Palm Pilot today to get an idea of
> typical program size today (on the Palm Pilot, applications
> larger than 100K are unusual, and indeed my brother's datebk4
> program, at about 450K is the largest application program in
> common use on that platform :-)

Sorry but this is an incorrect analogy. There are three classes of
computers: micro, mini and mainframes. PDP-11 was a mini computer,
that's right. Which means that the nowaday analog would be a
workstation, not the Palm Pilot.

> > The point was that among all arguments pro and cotra
> > including some feature into a universal and long living
> > system, a reference to balance between complexity and
> > functionality is the weakest one. Please note the words
> > "universal" and "long living".
>
> Sounds like you have not had much experience in the real world
> of language design, where this balance is THE primary issue in
> design considerations.

In which units do you measure complexity and functionality? Which
value of Balance = Complexity / Functionality is the goal. 2.5 of
"balance units"? (:-)) This is not a scientific issue. It is about
feeling and belief. From your experience you feel that MD would be
too expensive [= useless (:-))]. I respect your opinion, for I know
your qualification. But it is not enough for me to change my feeling
that MD will be universally adopted in the near future [MD C++
extensions can be already found in the internet]. It would be sad if
this issue would be another nail in the Ada's coffin.

> > IMO the first role should play such factors regularity,
> > correctness and volume.
>
> Sorry, that sentence is too garbled, I have no idea what
> "volume" refers to in the context of language design.

I used this word instead of "complexity". Because it seems that you
have reserved "complexity" for compiler implementation (:-)).

> Regularity (often referred to as orthogonality) is indeed
> a critical feature, and actually this is where it is very
> difficult to get a clear definition of MD (or MI for that
> matter :-)

Restrictions like "a type can be derived from only one base", or
"an operation shall dispatch on parameters of same type having
actual values of same type", or "not all types may have dispatching
subroutines", or "instances of packages having some interesting types
shall be global (instantiated at the lirary level)", or "a derived
type contains a representation of the base" are viewed (at
least by some language users) as irregularities. I would consider such
things as problems, no matter whether I or somebody else knows how to
solve these problems.

> Correctness is an odd concept in the language design
> environnment, unless you mean that something is correct if
> dmitry declares it correct (an approach you seem to have taken
> in the past). If you mean consistency in a formal sense, yes,
> then of course this is a necessary (but not sufficient)
> condition.

I am glad to hear this (:-))

> Language design is much harder than people think. Well meaning
> technical folks with a little bit of experience in language
> semantics, but no experience in full language design, often
> vastly underestimate the difficulties involved.

Did I say that MD is simple?

> > Anyway, let's see what will happen with MD in the static
> > typed languages in the next 5-10 years.
>
> My guess: nothing much. I just don't see any constituency that
> would push in favor of moving in this direction for statically
> typed languages. The arguments are quite weak (note that Dmitry
> has not been able to present any specific arguments, beyond the
> claim that binary operators require MD, but with no good
> examples).

Binary operators do not require MD. MD is required by dispatching
binary operators. And apart from my weak arguments:

1. [Not related to a specific language] Is MD a useful concept?

2. [In Ada context] Do we need MD?

> In practice in Ada, you can always achieve the effects of MD
> in specific instances, and the generalization is just not worth
> the effort, given how rarely it would be of use.

Well, such arguments can be applied to the tagged types in general, as
well as to any language feature, until the language reduces to
something assembler-like. You should admit that the common purpose
languages are evolving in the "slightly" opposite direction.

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93l89r$r9m$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:
> In article <93cagm$c1j$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:

> > Maybe I am wrong, but it seems that RM does not forbid to keep the
> > type tag separated from the value. Does it?
>
> No, it doesn't; it's just that the tag is not "part of" the value
> (regardless of where it is "kept").
>
> > Anyway the clear distinction of normal types and class-wide types is
> > an excellent (revolutionaly, IMO) concept. It is pity that Ada 95
> > didn't use all advantages of the concept. For instance, to have
> > multiple dispatch, or even, all types "tagged"!
>
> Interesting idea, but I don't know that I agree it's "a pity" that Ada
> didn't do these things. Ada is a practical language.  Making scalars,
> etc. carry a tag around wouldn't be worth it. It would really foul up
> system-level programming and interfacing to other languages.

No, you need a tag only in a class-wide. 90% of all code does not
involve class-wide values, references or pointers. I do not think that
Integer's + and - should be dispaching (:-)) even if Integer
is "tagged". 'Value and 'Image are much better candidates.

In any case if the tag is kept separately you can interface to all
other languages until you make dispatchig calls. To have it safe, there
should be a way to say which parameter of a primitive operation is
dispatching and which is not. If all parameters are non-dispatching,
you have a normal subroutine suitable to interface even with FORTRAN-IV.

> I don't see a whole lot of value in doing classwide programming on
> integers or arrays anyway (with plenty of opportunity for obscure
> code). Can't you get the same effect by declaring a tagged container,
> then deriving from that?

What about implementation of the attributes like 'Image, 'Read, 'Output
etc. as dispatching subroutines? I made no detailed investigation, but
I think that many currently hard-coded things could be then expressed
in the terms of the language.

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <93l8hm$rlp$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:
> In article <93e4e6$ucg$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> >
> > It is NOT "using all advantages of [a] concept" to insist that
> > it be used absolutely everywhere. On the contrary, that kind of
> > approach leads to a much more restrictive and less useful
> > expressive power.
>
> Very true.
>
> My favorite example is the notion of "purity" of OO languages, which
> holds that some good comes from the ability to say "everything is a
> class".  The only result is that you have to contort everything into
> _being_ a class for the sake of being able to say this, so for
> instance you have to have a "singleton" design pattern to work around
> not having packages with state, etc.

Actually there are two different concepts here. One is that all
language things are objects. Which is absurd because the word "all"
makes the term object useless. Another is that all types are derived
from the common ancestor. It is not so bad, but depends on what is
meant under "derived". The languages you mention "derive" all by the
way that has the described above effects. What is worse, is that they
are unsafe and inefficient. So a purely defined inheritance could be
a problem. Shall we trow it out then?

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[gasperon]

In article <93l2ok$in2$1@s1.read.news.oleane.net>,
  "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> wrote:
>
> with Ada.Text_IO;
> procedure Hello is
> begin
>     Ada.Text_IO.Put_Line ("Hello");
> end Hello;
>
> is 271 KB big with GNAT on Solaris.
>

Thierry, I am a bit surprised by your measurment, I just tried it
with GNAT 3.14w on both SOlaris and Linux and here is what I get:

   Solaris 2.5.1
   -------------------------------------
   GNAT/Ada object file size:    800 bytes
   GNAT/Ada executable size : 11,604 bytes

   Linux Red Hat 6.1
   -------------------------------------
   GNAT/Ada object file size:    916 bytes
   GNAT/Ada executable size :  6,420 bytes

As an interesting comparison data point the size of the object file
for the equivalent C program compiled with GNAT 3.14w/GCC is

   Solaris 2.5.1
   -------------------------------------
   GNAT/C object file size:   728 bytes
   GNAT/C executable size : 7,716 bytes

   Linux Red Hat 6.1
   -------------------------------------
   GNAT/C object file size:   868 bytes
   GNAT/C executable size : 6,484 bytes


-- Franco
   ACT Europe


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93modu$36k$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> Sorry but this is an incorrect analogy. There are three
> classes of computers: micro, mini and mainframes. PDP-11 was
> a mini computer, that's right. Which means that the nowaday
> analog would be a workstation, not the Palm Pilot.

Well perhaps you were not around those days, but your view
is not an accurate reflection of the situation then.

In those days, mini-computers were just that, tiny computers
with, by standards of the day, small memories and limited
capabilities.

Today, work stations typically have more processing power
(at least in CPU terms, if not in IO bandwidth) than mainframes
and often have very large memories (the notebook I am typing
on has half a gigabyte of physiscal memory, and many more
gigabytes of virtual memory).

So it is not the case today that work stations are somehow
small computers compared to mainframes, at least in terms
of the important parameter we are discussing which is memory
size.

In the days of the PDP-11, the remarkable thing was that people
could write small programs that had impressive functionality.
For example, Unix was a very small fraction of the size of
mainframe OS's. So I looked for an analogy today, and the
closest I could find was the Palm Pilot, where again, people
can write small programs with impressive functionality (of
course everything is relative, a typical Palm Pilot these
days has 8 megs of memory, whereas even the fanciest PDP 11's
only had 128K bytes :-)

In any case, if you want to talk about typical sizes of large
programs, you look at mainframes THEN, and NOW you can look
at ordinary PC's, since PC's have plenty of memory these days.


> In which units do you measure complexity and functionality?
> Which value of Balance = Complexity / Functionality is the
> goal. 2.5 of "balance units"? (:-))

It would be nice if these critical measures could be quantified
so easily, but they can't. That makes it all the harder, but
does not mean these can be ignored as criteria (surely you
don't go around an art gallery limiting yourself only to
objective criteria for judging quality). The analogy is not
at all unreasonable, since part of language design is precisely
related to human and aesthetic issues, as you would certainly
be painfully aware if you had ever been involved in formal
language design efforts.

> This is not a scientific issue. It is about
> feeling and belief.

If science to you is strictly restricted to things that can
be objectively measured (not all scientists would accept this
limitation (*)) then that's absolutely right. But it is
probably more accurate to replace "feeling and belief" with
expert judgment (going back to my earlier analogy, the
excellence of certain paintings is a little more than just
some individuals feeling and belief, it is the result of a
consensus of expert judgment).

> From your experience you feel that MD would be
> too expensive [= useless (:-))]. I respect your opinion, for
> I know your qualification.

You missed my point in earlier messages. If it was just me
that felt that way, you would be quite justified in your
reaction. But in fact this is an area in which there seems
to be clear consensus. If I find that my opinion is not shared
by anyone else then I conclude that either

 a) I am arguing my case incompetently
 b) I am wrong

I never end up being the 1 in an N-1 vote on language design
issues, since neither a) nor b) justifies such a position.

> But it is not enough for me to change my feeling
> that MD will be universally adopted in the near future

But an individual "feeling" is not very convincing if it is
not backed up by good arguments, especially when you are in
a small technical minority.

So far, you really have not presented any arguments.

Once again, the basic argument against MD is that the added
functionality does not justify the additional complexity.
One viewpoint I have found useful in language design is to
realize that adding *ANY* new feature to a language damages
it by increasing complexity. So the burden is to show that
the gain outweighs this damage. I do NOT accept the "PL/1
style" argument that says "never mind, if you don't want
to use this feature, you don't have to, so it can't harm you".

To make your case, why not do the following

  a) propose, in rough form, no need to tie up the details
  an MD addition to Ada

  b) show one example where this MD addition really adds
  to expressive power.

I think that's a reasonable request, the burden of proof is
definitely on your side for adding new features. What is
interesting then is to contrast the best possible solution
without MD to the example you show.

This is how a lot of the design work on Ada (and all other
programming languages) is conducted when it comes to looking
at new features. If you just sit around the table at a
standards committee meeting and say "I feel we should add
feature XXX", and don't add any supporting technical argument,
then you won't get far.

Saying that something should be done just for the sake of
uniformity is not good enough. yes, that is one argument, since
it may reduce complexity (**) but it is not enough!

> I used this word instead of "complexity". Because it seems
> that you have reserved "complexity" for compiler
> implementation (:-)).

Well see the (**) below, but actually I was talking about
complexity of the semantic definition here, not of the
implementation.

> Restrictions like "a type can be derived from only one base",
> or "an operation shall dispatch on parameters of same type
> having actual values of same type", or "not all types may
> have dispatching subroutines", or "instances of packages
> having some interesting types shall be global (instantiated
> at the lirary level)", or "a derived type contains a
> representation of the base" are viewed (at least by some
> language users) as irregularities. I would consider such
> things as problems, no matter whether I or somebody else
> knows how to solve these problems.

Yes, that's right, any non-unformity is a problem, but that
does not mean there is an acceptable solution.

Also, a casual approach to considering the semantics often
covers up complex details. For example, in the case of
multiple inheritance, the mess we get into when we have
common base classes.

> Did I say that MD is simple?

No, you didn't and of course that's a missing part of your
argument. I was hoping as I scrolled down your message to
find a specific technical example, but there is still none.
I think that the ONLY way you can convince people to add
a new feature (which apparently you understand to be
"not simple") is to show convincing examples.

(*) the issue of whether science should be about purely what
can be objectively observed and reasoned about is a very
old one. It actually is relevant to "computer science",
because there is an ongoing debate on whether it is indeed
a science. My own background is in Chemistry (my PhD was in
crystallography -- though to be fair, it was highly computer
related, I did the first fully computer automated computer
solution of a crystal structure, and amazingly some of my
ancient Fortran code is still in use over thirty years
later). I personally prefer to reserve the word science for
fields with a strong objective empirical component, where
the game is to construct theories that match observations,
and test the theories by experimentation. According to this
definitely, language design (and most of the rest of so-called
computer science) is NOT a science (and for sure social science
etc are not sciences either -- someone once said that any field
that feels compelled to call itself a science isn't one :-)
Certainly language design is not a science in the empirical
objective sense, we definitely do NOT have objective metrics
which can be used to determine that one language design is
better than another.

(**) One useful observation that I made during the Ada 95
language design effort was that everyone is in favor of
simplicity, and opposed to complexity, but in fact these
terms refer to lots of different things:

  1. Simplicity in implementation

  2. Simplicity in formal semantic description

  3. Simplicity of learning for non-experts

  4. Simplicity of resulting code in the language

  5. Simplicity of informal (text book) description

The trouble is that these are now different criteria, which
often are in exact opposition. Here is an example.

Records are a simple concept

Arrays are a simple concept

It is useful to have records have fields of any type

It is useful to have arrays that have dynamic length

BUT, what about records that have fields that are dynamic
length arrays. Well of course you want to allow that from
the point of view of uniformity of description (and indeed
Ada takes that position). This also aids ease of use and
makes programs simpler. HOWEVER, it is a very nasty glitch
in the implementation, and certainly makes the implementation
more complex, why? because the simple paradigm of record
implementation (fixed offsets from a base address) breaks.

Now, of course we have taken what I think is the right decision
here in Ada to settle for added complexity of implementation
to simplify the use of the language, but you see from this
example that simplicity is not such a simple concept :-)

Robert Dewar


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <3A5E4DE3.C4D55B70@brighton.ac.uk>,
  John English <je@brighton.ac.uk> wrote:

> Indeed. Java has to be rejected (no MI)


It is interesting to note that there is a strong camp in the
object oriented world that is very much opposed to MI,
precisely on the grounds that it destroys the simple clean
model of inheritance :-)


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

Re: Parameter Modes, In In Out and Out

[n_brunot]

In article <93n0vp$9b0$1@nnrp1.deja.com>,
  gasperon@act-europe.fr wrote:
> Thierry, I am a bit surprised by your measurment, I just tried it
> with GNAT 3.14w on both SOlaris and Linux and here is what I get:

Remember that most Gnat users have the public version.
The most recent one is 3.13p which still relies on an old gcc version.
Compiler switches (especially -g, -gnato and -Ox) gives very different
sizes, so it's useful to specify which switches you use.
Anyway if gnat 3.14 is really going to bring such improvements in exe
sizes, that's good news.


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

Re: Parameter Modes, In In Out and Out

[charlet]

> Remember that most Gnat users have the public version.

You will get very similar results with GNAT 3.13, it is simply a
matter of using the right options.

Arno


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

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93n2gk$amr$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <3A5E4DE3.C4D55B70@brighton.ac.uk>,
>   John English <je@brighton.ac.uk> wrote:
>
> > Indeed. Java has to be rejected (no MI)
>
> It is interesting to note that there is a strong camp in the
> object oriented world that is very much opposed to MI,
> precisely on the grounds that it destroys the simple clean
> model of inheritance :-)

There's also a faction that opposes Java's static strong typing.

I believe the argument is in the context of dynamic distributed
computing, but I don't understand it well enough to summarize it.

-- mark


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

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93mtn6$6t6$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93l8hm$rlp$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:
> > In article <93e4e6$ucg$1@nnrp1.deja.com>,
> >   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > >
> > > It is NOT "using all advantages of [a] concept" to insist that
> > > it be used absolutely everywhere. On the contrary, that kind of
> > > approach leads to a much more restrictive and less useful
> > > expressive power.
> >
> > Very true.
> >
> > My favorite example is the notion of "purity" of OO languages, which
> > holds that some good comes from the ability to say "everything is a
> > class".  The only result is that you have to contort everything into
> > _being_ a class for the sake of being able to say this, so for
> > instance you have to have a "singleton" design pattern to work
around
> > not having packages with state, etc.
>
> Actually there are two different concepts here. One is that all
> language things are objects. Which is absurd because the word "all"
> makes the term object useless.

Yes.  Alex Stepanov of STL renown makes that point in this interview:

    http://www.stlport.org/resources/StepanovUSA.html

The problem I have with the whole premise of "pure OO", though, is the
equivocation on the terms "object" and "object oriented".  OO is about
the idea that you deal with abstractions (interfaces) and not with
representations.  That plays out in three concepts: encapsulation,
inheritance, and dynamic polymorphism.  Making "everything a class"
doesn't singularly facilitate any of these three aspects in better form
or greater measure; what it facilitates is just programming where
everything is a class!  Instead of having constructs that fit their
use, you have one construct whose use is then specialized (sometimes in
syntactically expensive ways) and then you have to figure out the use
by inspection.

In some ways I prefer the term "abstraction-oriented programming",
because the term "OOP" has become so muddled.




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

Re: Parameter Modes, In In Out and Out

[Dale Stanbrough]

Robert Dewar wrote:

>  I personally prefer to reserve the word science for
> fields with a strong objective empirical component, where
> the game is to construct theories that match observations,
> and test the theories by experimentation.


Which, interestingly, is a very good description of debugging.
I find it amusing that what is often considered the lowest form
of "computer science" is the closest to the process of science
that most computer people get to.


Dale

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <dale-E86DFE.09024813012001@news-server>,
  Dale Stanbrough <dale@cs.rmit.edu.au> wrote:

> Which, interestingly, is a very good description of
> debugging. I find it amusing that what is often considered
> the lowest form of "computer science" is the closest to the
> process of science that most computer people get to.

Very true, I had not specifically made this identification
before, but you are absolutely right, and indeed, part of
the skill in debugging is exactly the same kind of careful
experimentation and theory formation that is characteristic
of empirical science. This is especially true if you are
dealing with a large program whose structure you are not
completely familiar with.

The other view of debugging is that it is for some people
a kind of computer RPG game "in the large array on the right,
you spot an uninitialized pointer ...."

I definitely note that some people enjoy debugging a lot, and
one of the interesting dynamics is that if you enjoy debugging,
then there is not much incentive to write code right the first
time. Personally I like programming, but I hate debugging, so
I have a big incentive to get things right first time (and
I find the clean room approach quite appealing :-)


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93nshs$400$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:

> In some ways I prefer the term "abstraction-oriented
> programming", because the term "OOP" has become so muddled.

Well I think the notion of OOP *should* be clear enough, but
many people use the term to refer to abstraction-oriented
programming, which is of course a far more extensive concept.
Similarly, for a lot of programmers, an object and an abstract
data type are equivalent concepts.

I think it was a right decision in the Ada design to avoid
giving too much of a distinuished position to OOP as such,
since it is only one tool in the kit of the
abstraction-oriented programmer.


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

Re: Parameter Modes, In In Out and Out

[Larry Kilgallen]

In article <93oa42$fsh$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> I definitely note that some people enjoy debugging a lot, and
> one of the interesting dynamics is that if you enjoy debugging,
> then there is not much incentive to write code right the first
> time. Personally I like programming, but I hate debugging, so
> I have a big incentive to get things right first time (and
> I find the clean room approach quite appealing :-)

The person doing the debugging might not be the person who wrote
the code.

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <eiviJtYj+A7W@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> The person doing the debugging might not be the person who
> wrote the code.

Possible, though unusual in most environments ... of course
if you use a clean room approach then there IS no debugging,
so who does it is not an issue.


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

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:

> In the days of the PDP-11, the remarkable thing was that people
> could write small programs that had impressive functionality.

Yes, EDT (and later LSE) is the best text editor of all times.

> 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.

> In any case, if you want to talk about typical sizes of large
> programs, you look at mainframes THEN, and NOW you can look
> at ordinary PC's, since PC's have plenty of memory these days.

Let's be scientific (:-)) and build a histogram: number of computers
over the model price. The mediane of such histogram in 1985 will
correspond to the computers comparable with PDP-11. Today it is a PC.
Now take a "simple" program: a text processor. In 1985 for PDP-11 it
was EDT + ROFF (only a fanatic would use a Unix on PDP-11 (:-)). Size
~50K. Now turn to PC and, well, what about MS-Word? (:-))

> > This is not a scientific issue. It is about
> > feeling and belief.
>
> If science to you is strictly restricted to things that can
> be objectively measured (not all scientists would accept this
> limitation (*)) then that's absolutely right. But it is
> probably more accurate to replace "feeling and belief" with
> expert judgment (going back to my earlier analogy, the
> excellence of certain paintings is a little more than just
> some individuals feeling and belief, it is the result of a
> consensus of expert judgment).

Yes, a consensus of expert's feelings (:-)). [ Actually this is a
good criterion to decide whether something is a science. Scientific
issues are not subject of voting. ]

> If I find that my opinion is not shared
> by anyone else then I conclude that either
>
>  a) I am arguing my case incompetently
>  b) I am wrong
>
> I never end up being the 1 in an N-1 vote on language design
> issues, since neither a) nor b) justifies such a position.

Robert, you are too merciless to yourself. Even in such pure sciences
as mathematcs there is no consensus. Especially if it is about
fundamental issues like set theory. I think you would argree that
the issues of acceptance of MD and MI are fundamental for programing.

> > But it is not enough for me to change my feeling
> > that MD will be universally adopted in the near future
>
> But an individual "feeling" is not very convincing if it is
> not backed up by good arguments, especially when you are in
> a small technical minority.

Absolutely.

> So far, you really have not presented any arguments.

First, we have not yet decided what is argued. Is is about MD in
general? Is it about Ada extension, or an intrusive Ada redesign?

Second, MD is extremely obscure. Alone the question whether this
obscurity an inherent property of MD, or we simply do not understand
something, is a good theme for a plethora of PhD works.

You surely do not think that I am able to produce a complete proposal,
how to incorporate MD in Ada (:-)).

> I do NOT accept the "PL/1 style" argument that says "never mind, if
> you don't want to use this feature, you don't have to, so it can't
> harm you".

I am with you here (I did my MS work in PL/1). Though it was PL/1 that
opened exceptions and overloading to me. Interesting is that from
the height of our current knowledge they were purely implemented.

> To make your case, why not do the following
>
>   a) propose, in rough form, no need to tie up the details
>   an MD addition to Ada
>
>   b) show one example where this MD addition really adds
>   to expressive power.
>
> I think that's a reasonable request, the burden of proof is
> definitely on your side for adding new features. What is
> interesting then is to contrast the best possible solution
> without MD to the example you show.

I agree with you. But this is a good way for relatively small, well
defined and "indestructive" proposals. Like "should we have fixed
numeric types of e-radix?" (:-))

In contrary to this, the MD issue can potentially affect all parts
of the language, which is not the smallest one. It is more like,
someone says 'It would be nice to fly to stars', another answers
'well, give us the blueprints of the starship'. Technically the later
one is correct. But he should be prepared to reconsider the idea
time to time (:-)).

> Also, a casual approach to considering the semantics often
> covers up complex details. For example, in the case of
> multiple inheritance, the mess we get into when we have
> common base classes.

"Mess" is not an argument, if I dare quote you (:-)). Common bases
could be made distinguishable by an explicit inheritance path
specification and enforcing naming of the immediate bases (like names
of subroutine parameters). Converting to a class-wide should be
parametrized by the path. For overriding there are many options to
consider. It seems that all could be statically checked. C++ makes MI
unsatisfactory, but still reasonable.
[ no, this is not a proposal (:-)) ]

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Fri, 12 Jan 2001 mark_lundquist@my-deja.com wrote:
> In article <93n2gk$amr$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <3A5E4DE3.C4D55B70@brighton.ac.uk>,
> >   John English <je@brighton.ac.uk> wrote:
> >
> > > Indeed. Java has to be rejected (no MI)
> >
> > It is interesting to note that there is a strong camp in the
> > object oriented world that is very much opposed to MI,
> > precisely on the grounds that it destroys the simple clean
> > model of inheritance :-)
> 
> There's also a faction that opposes Java's static strong typing.
> 
> I believe the argument is in the context of dynamic distributed
> computing, but I don't understand it well enough to summarize it.

I think the argument is actually simple, and you can reduce it to
considering the case of input/output. If you want to read "objects" 
stored in some persistent memory by some other program how do you
statically determine their type? Well, the simple answer is, you don't, 
you use dynamic typing. Yes, I've dramatically oversimplified but that's 
it in a nutshell. 

Being an impurist, my response is that type safe object IO is probably
a good example of where dynamic typing should be integrated into a
statically typed language, but that static typing should be the default. 

-- Brian

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

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:
>
> > In the days of the PDP-11, the remarkable thing was that
people
> > could write small programs that had impressive
functionality.
>
> Yes, EDT (and later LSE) is the best text editor of all
> times.

OUCH! that's a really peculiar viewpoint, still editors are
oddly personal things. So no point in discussing.

> > 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.

> > In any case, if you want to talk about typical sizes of
> > large
> > programs, you look at mainframes THEN, and NOW you can look
> > at ordinary PC's, since PC's have plenty of memory these
> > days.
>
> Let's be scientific (:-)) and build a histogram: number of
> computers
> over the model price. The mediane of such histogram in 1985
> will correspond to the computers comparable with PDP-11.
> Today it is a PC.

Totally inaccurate, today it is 8 bit microprocessors, the
kind you have in your cell phone and watch, but so what?

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.

A friend of mine at the time remarked "what's the point of
writing portable code, write in 360 ASM, then your program
will run on 90% of all machines). It is interesting to notice
that when we wrote 360 SPITBOL, virtually ALL universities had
IBM 360's, there was very little demand for any other machine,
then later on there was some small PDP 11 demand that developed
as small colleges acquired PDP 11's running Unix.

> Now take a "simple" program: a text processor. In 1985 for
> PDP-11 it
>  was EDT + ROFF (only a fanatic would use a Unix on PDP-11
> (:-)).

1985 is very very late for this discussion, that is four years
after the PC had appeared, by that time the PDP 11 was pretty
much disappearing from universities, at least in the US.

I am talking about a MUCH earlier time period, a decade
earlier than that. Of course I don't know where you were
at the time, and perhaps your environment was quite different.

I never saw a PDP 11 in a university running other than Unix
in the US, no other choice would have made sense.

> Second, MD is extremely obscure. Alone the question whether
> this obscurity an inherent property of MD, or we simply do
> not understand something, is a good theme for a plethora of
> PhD works.

I am not sure what you mean by obscure here, it is an odd
word in this context, what are you trying to say?


> You surely do not think that I am able to produce a complete
> proposal, how to incorporate MD in Ada (:-)).

On the contrary, I assume that if you are arguing this point,
you understand both Ada and MD well enough to do exactly that,
and for instance that you are familiar with CLOS. It is really
not that hard to propose the basic outline of an MD facility
for Ada 83, we sketched out various ideas during the design
process, but nothing that was reasonable.

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.

If you can't get this far, then there is no point in even
discussing what the details are.

I am beginning to worry that you are promoting MD without a
clear idea of how it would work, or how it would be used,
just on the basis of some vague theoretical understanding.

> I am with you here (I did my MS work in PL/1). Though it was
> PL/1 that opened exceptions and overloading to me.

Surely overloading was familiar from Algol 68?

> > To make your case, why not do the following
> >
> >   a) propose, in rough form, no need to tie up the details
> >   an MD addition to Ada
> >
> >   b) show one example where this MD addition really adds
> >   to expressive power.
> >
> > I think that's a reasonable request, the burden of proof is
> > definitely on your side for adding new features. What is
> > interesting then is to contrast the best possible solution
> > without MD to the example you show.
>
> I agree with you. But this is a good way for relatively
> small, well defined and "indestructive" proposals. Like
> "should we have fixed numeric types of e-radix?" (:-))

No, it's the right wway to get started on ANY language design
issue, if you can't show one roughly sketched example, you
are not going to get anywhere, or convince anyone that your
idea has any merit at all.

> In contrary to this, the MD issue can potentially affect all
> parts of the language, which is not the smallest one. It is
> more like, someone says 'It would be nice to fly to stars',
> another answers 'well, give us the blueprints of the
> starship'.

Now I am finding this very odd. Are you really familiar with
MD? In which language do you know this feature well? If you
understand the feature, producing a simple example translated
to the Ada arena should be very straightforward, certainly it
is something that I would expect anyone discussing this issue
to be able to knock out.


> > Also, a casual approach to considering the semantics often
> > covers up complex details. For example, in the case of
> > multiple inheritance, the mess we get into when we have
> > common base classes.
>
> "Mess" is not an argument, if I dare quote you (:-)). Common
> bases could be made distinguishable by an explicit
> inheritance path specification and enforcing naming of the
> immediate bases (like names of subroutine parameters).
> Converting to a class-wide should be
> parametrized by the path. For overriding there are many
> options to
> consider. It seems that all could be statically checked. C++
> makes MI
> unsatisfactory, but still reasonable.
> [ no, this is not a proposal (:-)) ]

I assume you are familiar with Tucker's proposal in this
area (the above seems a bit rambling to me, I really can't
tell what you mean). Tucker's proposal seems exactly the
right direction to follow if you want to pursue MI.



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

Re: Parameter Modes, In In Out and Out

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]


<mark_lundquist@my-deja.com> a �crit dans le message news: 93l8hm$rlp$1@nnrp1.deja.com...
> In article <93e4e6$ucg$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> >
> > It is NOT "using all advantages of [a] concept" to insist that
> > it be used absolutely everywhere. On the contrary, that kind of
> > approach leads to a much more restrictive and less useful
> > expressive power.
> >
>
> Very true.
>
> My favorite example is the notion of "purity" of OO languages, which
> holds that some good comes from the ability to say "everything is a
> class".  The only result is that you have to contort everything into
> _being_ a class for the sake of being able to say this, so for instance
> you have to have a "singleton" design pattern to work around not having
> packages with state, etc.
>
Very Very true :-)
Too often, people slip from "anything can be done with classes" to "anything must  be done with classes".

I'm always amazed by people who value "pure OO" language. It's like having just one tool in one's tool box, and being proud of it.

Everything can be done with a swiss army knife, so everything must be done with a swiss army knife. You don't need that ol' chain
saw any more. Want to cut a big tree ? all you need is a swiss army knife (and patience).

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Sat, 13 Jan 2001, Robert Dewar wrote:
> dmitry6243@my-deja.com wrote:
> > You surely do not think that I am able to produce a complete
> > proposal, how to incorporate MD in Ada (:-)).
> 
> On the contrary, I assume that if you are arguing this point,
> you understand both Ada and MD well enough to do exactly that,
> and for instance that you are familiar with CLOS. It is really
> not that hard to propose the basic outline of an MD facility
> for Ada 83, we sketched out various ideas during the design
> process, but nothing that was reasonable.
> 
> 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.

I'd like to be able to write something like 

package Shape_Output is 
    type Shape_Type is tagged private;
    ...
    type Output_Type is tagged limited private;

    procedure Write(Shape : in Shape_Type; Output in out Output_Type);
private
    ...
end Shape_Output;

where write is a primitive operation of Shape_Type and Output_Type and 
the dispatching can select based on both which code gets called. :-)

> If you can't get this far, then there is no point in even
> discussing what the details are.

Is that far enough? 

Before anyone answers, I'm familiar with the double dispatching idiom, and
the Visitor pattern, and Dylan, and I actually believe the designers of
Ada were right not to provide direct support for this in Ada given what we
currently know.

I also think that some form of downward funarg would be a lot more useful
in day-to-day programming than multimethods, though I guess I wouldn't
call Ada crippled or hobbled. I'd just say that it's an annoyance that I 
wish wasn't there. (Sorry, couldn't resist :)

> I am beginning to worry that you are promoting MD without a
> clear idea of how it would work, or how it would be used,
> just on the basis of some vague theoretical understanding.

From my POV, its clear that it could be useful, but when you think about
how it should work and how to implement it in Ada you start wondering 
about the gain. 

> > > To make your case, why not do the following
> > >
> > >   a) propose, in rough form, no need to tie up the details
> > >   an MD addition to Ada
> > >
> > >   b) show one example where this MD addition really adds
> > >   to expressive power.
> > >
> > > I think that's a reasonable request, the burden of proof is
> > > definitely on your side for adding new features. What is
> > > interesting then is to contrast the best possible solution
> > > without MD to the example you show.

How is the example of object IO above? I think you can generalize that 
to lots of similar cases. What I'm really curious about is how many 
good, natural examples of MM use more than two dispatching arguments. 
Anyone have a good one? 

> I assume you are familiar with Tucker's proposal in this
> area (the above seems a bit rambling to me, I really can't
> tell what you mean). Tucker's proposal seems exactly the
> right direction to follow if you want to pursue MI.

Yes, Tucker's note on adding Java style interfaces is really worth a read, 
and I'd advise anyone who wants to contribute their two cents to Ada 0X 
language design discussions to just read that, and also Tucker's proposal 
about blending protected types and tagged types better. 

And I guess it goes without saying that I hope GNAT is quick to implement
some of these ideas...

-- Brian

Re: Parameter Modes, In In Out and Out

[Jeffrey Carter]

Brian Rogoff wrote:
> 
> I also think that some form of downward funarg would be a lot more useful
> in day-to-day programming than multimethods, though I guess I wouldn't
> call Ada crippled or hobbled. I'd just say that it's an annoyance that I
> wish wasn't there. (Sorry, couldn't resist :)

There is a basic consistency issue here. Ada does things safely by
default, but always allows the developer to get around the rules when
appropriate by using something named Unchecked_XXX. In the area of
access-to-object values, this is 'Unchecked_Access. However, in the area
of passing an access-to-subprogram value to a subprogram, there is no
way to get around the rules. This is an unfortunate deviation from the
basic philosophy.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article
<Pine.BSF.4.21.0101131407170.18026-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> How is the example of object IO above? I think you can
> generalize that  to lots of similar cases.

But this example is easily written using the current idioms,
the issue being one of ease of inheritance, but it is not
clear that this is a compelling argument.

> And I guess it goes without saying that I hope GNAT is quick
> to implement some of these ideas...

Currently we don't see any demand for doing anything in this
area, so there are no plans. It's a lot of work, and it is not
something that will get done without a very clear demand. I
certainly agree it would be nice to use GNAT as an experimental
vehicle for looking at some of these issues.

Perhaps the most practical thing is to devise some kind of
source-to-source translation kludge as a first experiment,
since that can be done without digging into what are some of
the most delicate parts of the front end (you would have to
know a LOT about GNAT internals to implement Tuck's proposal
:-)



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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <3A6140CB.63EE9B8F@acm.org>,
  Jeffrey Carter <jrcarter@acm.org> wrote:
> Brian Rogoff wrote:
> However, in the area of passing an access-to-subprogram value
> to a subprogram, there is no way to get around the rules.
> This is an unfortunate deviation from the basic philosophy.

"the basic philsophy"

The word "the" here is mischosen. The Ada design follows a
set of guidelines (basic philosophical principles if you
really want to get that grandiose), and what you refer to
is just one of them. Another is ease of implementation, and
in particular, an easy path for migration of Ada 83
technologies.

Tuck once said that he was dubious about the possibility of
adapting Ada 83 technology to Ada 95, and you will notice that
Averstar (Intermetrics) did indeed start from scratch rather
than adapt their previous Ada 83 technology. GNAT also started
from scratch, but that's a bit misleading, because there was
no production Ada 83 compiler on which GNAT could have been
built (Ada/Ed was a different kind of beast).

However, Tuck was pessimistic, we have seen that it is possible
to adapt Ada 83 technologies to Ada 95, and there is more than
one example, a notable example is the Rational technology.

A critical guideline (philosophical principle?) was that
existing Ada 83 runtime models be reusable as far as possible.

In the case of Unchecked_Access, it is trivial for an
implementation to omit a check, so that is no big deal.

But Unrestricted_Access (the GNAT attribute that gives Jeffrey
what he wants) is not just a matter of omitting a check, it
requires handling non-local references correctly. Now in the
case where you use a static link approach, as GNAT does (since
that's what gcc had chosen to use for GNU C), then it is indeed
trivial to implement Unrestricted_Access, and indeed for GNAT,
it is zero work, just a matter of omitting an accessibility
check.

But for run-time models using displays, implementing
Unrestricted_Access is tricky (one vendor at one Ada 95
meeting used stronger language, I believe "nightmare"
was the word used :-)

If you ask your vendor "Gee, I kind of like the ACT
Unrestricted_Access attribute, can you implement this, the
answer will hugely depend on whether displays or static
links are used".

So yes, the failure to provide this capability is uncomfortably
inconsistent with one guideline, but was at the time mandated
by another guideline.

Was it a good idea to have this restriction? Hard to say in
this particular case. It is certainly the case where
transitional implementation concerns of existing vendors
most specifically impacted the Ada 95 design in what I
think most people would say was a negative manner (certainly
we find that the 'Unrestricted_Access attribute is invaluable
in many contexts).

Robert Dewar
Ada Core Technologies


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

Re: Parameter Modes, In In Out and Out

[Jeffrey Carter]

Robert Dewar wrote:
> 
> In article <3A6140CB.63EE9B8F@acm.org>,
>   Jeffrey Carter <jrcarter@acm.org> wrote:
> > However, in the area of passing an access-to-subprogram value
> > to a subprogram, there is no way to get around the rules.
> > This is an unfortunate deviation from the basic philosophy.
> 
> "the basic philsophy"
> 
> The word "the" here is mischosen. The Ada design follows a
> set of guidelines (basic philosophical principles if you
> really want to get that grandiose), and what you refer to
> is just one of them.

This is true. I used "the" to mean the principal mentioned above, not to
imply that this is the only guideline used in the revision process.
Also, this guideline is apparent to application developers, while ease
of migration for Ada-83 vendors is not.

-- 
Jeff Carter
"Go and boil your bottom."
Monty Python & the Holy Grail

Re: Parameter Modes, In In Out and Out

[n_brunot]

In article <93neoi$mml$1@nnrp1.deja.com>,
  charlet@gnat.com wrote:
> You will get very similar results with GNAT 3.13, it is simply a
> matter of using the right options.

I'd like to know which options you use to get the executable sizes we
are talking about
we are talking of an executable size around 10 000 bytes and even less,
which is far from being what I get with 3.12p and 3.13p
for example
gnatmake -O2 -gnatpn hello -largs -s
gives much bigger size on all platforms I tried (WinNT, Solaris, Irix)


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

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Sun, 14 Jan 2001, Robert Dewar wrote:
> In article
> <Pine.BSF.4.21.0101131407170.18026-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > How is the example of object IO above? I think you can
> > generalize that  to lots of similar cases.
> 
> But this example is easily written using the current idioms,
> the issue being one of ease of inheritance, but it is not
> clear that this is a compelling argument.

Sure, I hope it was clear that I "kind of" agree, since I included a 
smiley and mentioned that I'm aware of the idioms. Clearly, MD is 
"cleaner" at some level but that argument could be used for including
every feature in a language. 

I'm still wondering if anyone (Dmitry?) can come up with some good 
(natural, commonly occurring, etc.) examples which use triple or 
n-tuple dispatch where n > 2. All of the examples I've run into so 
far are double-dispatch.

> > And I guess it goes without saying that I hope GNAT is quick
> > to implement some of these ideas...
> 
> Currently we don't see any demand for doing anything in this
> area, so there are no plans. It's a lot of work, and it is not
> something that will get done without a very clear demand. I
> certainly agree it would be nice to use GNAT as an experimental
> vehicle for looking at some of these issues.

Well, surely you read the note about the ESA project which eschewed 
Ada in favor of C++ on account of the inability to do Java style 
MI of interface in Ada? That may not count as customer demand, but 
it is an interesting data point nonetheless. 

-- Brian

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Sun, 14 Jan 2001, Jeffrey Carter wrote:
> Brian Rogoff wrote:
> > 
> > I also think that some form of downward funarg would be a lot more useful
> > in day-to-day programming than multimethods, though I guess I wouldn't
> > call Ada crippled or hobbled. I'd just say that it's an annoyance that I
> > wish wasn't there. (Sorry, couldn't resist :)
> 
> There is a basic consistency issue here. Ada does things safely by
> default, but always allows the developer to get around the rules when
> appropriate by using something named Unchecked_XXX. In the area of
> access-to-object values, this is 'Unchecked_Access. However, in the area
> of passing an access-to-subprogram value to a subprogram, there is no
> way to get around the rules. This is an unfortunate deviation from the
> basic philosophy.

I appreciate the "safe by default" aspect of Ada. I'd prefer that downward
funargs be integrated safely into Ada, *not* by loosening Unchecked_Access 
or providing a GNAT style Unrestricted_Access attribute. Robert Duff had a 
safe downward funargs proposal which he has resubmitted. 

-- Brian

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <93sqq3$nng$1@nnrp1.deja.com>,
  n_brunot@my-deja.com wrote:

> gnatmake -O2 -gnatpn hello -largs -s
> gives much bigger size on all platforms I tried (WinNT,
> Solaris, Irix)

Well of course -gnatn is a request to make the executable
larger, not smaller! But that is, I would expect, a trivial
effect here. The important thing if you want a small executable
is to link dynamically instead of statically (usually when
there is a comparison of Ada vs C which shows C much smaller,
this is a significant factor in the difference).


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <3A61EC64.A61FDF61@acm.org>,
  Jeffrey Carter <jrcarter@acm.org> wrote:
> Also, this guideline is apparent to application developers,
> while ease of migration for Ada-83 vendors is not.

Indeed! Actually that's a special case that ease (and
realiability) of implementation are criteria that are not
very visible (or easy to evaluate) from an application
developer point of view. There are lots of things that
would make life easier for a programmer that would not
make implementors happy.

A good example is overloading. The clean definition of
overloading would simply be that for any expression if
there is one interpretation, then its right, if there
is more than one, it is wrong.

Although that is the general spirit of the overloading
rules, it turns out we have to make some nasty exceptions,
and make some things illegal even though there is only
one possible interpretation, to keep things reasonable :-)


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

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article
<Pine.BSF.4.21.0101141234130.2654-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Sure, I hope it was clear that I "kind of" agree, since I
> included a  smiley and mentioned that I'm aware of the
> idioms. Clearly, MD is  "cleaner" at some level but that
> argument could be used for including every feature in a
> language.

Yes indeed, that was clear, and I entirely agree with
everything you say here.
>
> I'm still wondering if anyone (Dmitry?) can come up with some
> good  (natural, commonly occurring, etc.) examples which use
> triple or  n-tuple dispatch where n > 2. All of the examples
> I've run into so far are double-dispatch.

Right, indeed examples would be interesting. I have been trying
to provoke Dmitry to come up with examples, but so far without
success :-)

> Well, surely you read the note about the ESA project which
> eschewed  Ada in favor of C++ on account of the inability to
> do Java style  MI of interface in Ada? That may not count as
> customer demand, but  it is an interesting data point
> nonetheless.

Well it certainly does not count as customer demand :-) As far
as I know the ESA did not even investigate the possibility of
whether this feature could be added to Ada (if they consider
Java as potentially usable, then obviously language standards
are not a consideration :-)

But more to the point, when you here someone say

I am choosing language X instead of Ada because Ada does not
have Y.

Then it does not mean that if Ada *did* have Y, they would
have chosen Ada.

I agree it is worth pursuing, but if the ESA is saying that
the only way they can make their birds fly is to use Java
style MI, then that's not very convincing!


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

Re: Parameter Modes, In In Out and Out

[n_brunot]

In article <93t4bi$v9t$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> Well of course -gnatn is a request to make the executable
> larger, not smaller! But that is, I would expect, a trivial
> effect here. The important thing if you want a small executable
> is to link dynamically instead of statically (usually when
> there is a comparison of Ada vs C which shows C much smaller,
> this is a significant factor in the difference).

And you can check that there is no effect on executable size in this
case :-)
Now the question was quite simple, and one line for the answer should
be enough.
Which is the gnatmake command line we must use to get this executable
size with gnat 3.12p or 3.13p ?
To avoid endless discussion about platforms or anything else, can
anybody provide the gnatmake command for the "Hello" procedure, on
WInNT, Solaris or Irix with either 3.12p or 3.13p and get less than 10
000 bytes for the executable size ?


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

Re: Parameter Modes, In In Out and Out

[dmitry6243]

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/

Re: Parameter Modes, In In Out and Out

[Brian Rogoff]

On Sun, 14 Jan 2001, Robert Dewar wrote:
> In article
> <Pine.BSF.4.21.0101141234130.2654-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > I'm still wondering if anyone (Dmitry?) can come up with some
> > good  (natural, commonly occurring, etc.) examples which use
> > triple or  n-tuple dispatch where n > 2. All of the examples
> > I've run into so far are double-dispatch.
> 
> Right, indeed examples would be interesting. I have been trying
> to provoke Dmitry to come up with examples, but so far without
> success :-)

I was actually of a similar disposition as Dmitry a few years ago w.r.t 
MD, but as I studied the issue more and looked at my own code in Ada and 
similar languages I managed to convince myself that it wouldn't be worth
it in Ada. Any CLOS programmers out there with different opinions? I never 
used Common Lisp enough to have it "at my fingertips" so maybe there are 
things I've missed.

I have bigger fish to fry now too. Why worry about MD when there are quite
a few aspects of protected types that need fixing? IMO, a good way to
judge if something qualifies as a potential Ada enhancement is if you have 
an actual coding experience with Ada where a (missing) feature caused pain
and the workaround was insufficient. For instance, the Rosen trick has 
lessened my pain at the lack of out params in functions so that even
though it seems naughty I won't complain about this flaw again. 

> > Well, surely you read the note about the ESA project which
> > eschewed  Ada in favor of C++ on account of the inability to
> > do Java style  MI of interface in Ada? That may not count as
> > customer demand, but  it is an interesting data point
> > nonetheless.
> 
> Well it certainly does not count as customer demand :-) As far
> as I know the ESA did not even investigate the possibility of
> whether this feature could be added to Ada (if they consider
> Java as potentially usable, then obviously language standards
> are not a consideration :-)

OK wiseguy, joke noted. They actually went with C++, and there library 
relies on conventions to restrict MI use to Java style, with pure abstract 
virtual base classes representing interfaces. 

> But more to the point, when you here someone say
> 
> I am choosing language X instead of Ada because Ada does not
> have Y.
> 
> Then it does not mean that if Ada *did* have Y, they would
> have chosen Ada.

Understood. Ada has lots of stuff C++ doesn't have. The lack of nested 
subprograms (with lexical scope) in a language is real turn-off, IMO. 

> I agree it is worth pursuing, but if the ESA is saying that
> the only way they can make their birds fly is to use Java
> style MI, then that's not very convincing!

No, I think their argument is more along the lines of "We found this 
style of OO to enhance reusability and maintainability", and expressing it
in Ada (with the self referential access discriminant trick) is a clumsy. 
For pure interface style programming, I see their point. Access discriminants 
provide a decent way to do MI of implementation (IMO) but Java style
interfaces do seem to hit a nice "sweet spot" of safe MI usage and
providing direct syntactic support for this in the language is worth
looking at. 

You're probably right that a preprocessor which deals with the clunky 
access discriminant stuff is a better fast track to a prototype than 
modifying GNAT. 

-- Brian

Re: Parameter Modes, In In Out and Out

[Georg Bauhaus]

Robert Dewar (robert_dewar@my-deja.com) wrote:

: If science to you is strictly restricted to things that can
: be objectively measured

O.K. whatever "objectively" might mean objectively
(yes, I know the model ;/).


: and test the theories by experimentation. According to this
: definitely, ...
: for sure social science
: etc are not sciences either

Please, I'm suprised, no such unsupportable claims from someone
who uses to require arguments.  I'm not sure what exact notion of
social science etc. you have, but I know one notion usually held
up by engineers and nat. "scientist",  about soft/hard, exact/inexact
etc sciences  that is largely based on ignorance and aquired blind spots
(anologous to "Ada is dead").

But that's OT on cla, of course

Georg Bauhaus

Re: Parameter Modes, In In Out and Out

[FAROOQATIF]

out parameters send out data without modifying it, and in out parameters can
take in data, change it and sent out as a different value.

Re: Parameter Modes, In In Out and Out

[mark_lundquist]

In article <93oa9k$fvc$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93nshs$400$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:
>
> > In some ways I prefer the term "abstraction-oriented
> > programming", because the term "OOP" has become so muddled.
>
> Well I think the notion of OOP *should* be clear enough, but
> many people use the term to refer to abstraction-oriented
> programming, which is of course a far more extensive concept.
> Similarly, for a lot of programmers, an object and an abstract
> data type are equivalent concepts.
>
> I think it was a right decision in the Ada design to avoid
> giving too much of a distinuished position to OOP as such,
> since it is only one tool in the kit of the
> abstraction-oriented programmer.


As near as I can tell, OOP means either (a) class-oriented programming,
or (b) inheritance (type extension) + polymorphism (dynamic dispatch).

Class-oriented programming, in my opinion, is a weak concept.  But if
all that is meant is type extentsion and polymorphism, then just as you
say they are one tool of many in the kit (and not really deserving of
such a grandiloquent designation as Object Oriented Programming).

That's why I think OOP is such a crummy term.



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

Multiple dispatch (was Re: Parameter Modes, In In Out and Out

[mark_lundquist]

The trail has kind of gone cold on this, but oh well..
(Why do you think they call it "Deja"? :-)

In article <93v898$k80$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:

> In article <93q6cd$r3k$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> >
> > 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.

[Dmitri's example:]
> --
> -- 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.

If they expected triple dispatch, then they don't know Ada :-)

Maybe they really expected covariance, in which case they should have
used a generic instead.

Another possibility is that the inputs to Compute should be of type
FuzzyNumber, not FuzzyNumber'Class.  Users of Compute would upcast as
necessary.  (However, they somehow have to have some reason to believe
that upcasting yields a meaningful result, which is hard to know
without seeing into the implementations of the abstractions.  This is a
general difficulty with programming by extension).

> 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.

I'm not a computer scientist, and I haven't ever studied multiple
dispatch, so maybe this is a naive question... but don't you now have a
problem with cross-coupled sibling dependencies?  Suppose I create
another type Wild_And_Wooly_Number, derived also from FuzzyNumber?  How
do you fill in your table then?

Mark Lundquist


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

Re: Multiple dispatch (was Re: Parameter Modes, In In Out and Out

[dmitry6243]

In article <95dm8r$a9a$1@nnrp1.deja.com>,
  mark_lundquist@my-deja.com wrote:

> If they expected triple dispatch, then they don't know Ada :-)

Well, in fact Ada does have "MD", defined as follows. If all tags are
same, then dispatch happens as it is expected. If the tags differ the
call is "dispatched" to a "method" that raises an exception. (Quotation
marks are placed for purists (:-)). Run-time exception is an obvious
problem and I can easily imagine applications where such behaviour
would be unacceptable.

> Maybe they really expected covariance, in which case they should have
> used a generic instead.
>
> Another possibility is that the inputs to Compute should be of type
> FuzzyNumber, not FuzzyNumber'Class.  Users of Compute would upcast as
> necessary.  (However, they somehow have to have some reason to believe
> that upcasting yields a meaningful result, which is hard to know
> without seeing into the implementations of the abstractions.  This is
> a general difficulty with programming by extension).

That's another question. No programming by extension was intended. It
was rather an attempt to have different respresentations for same
thing (FuzzyNumber).

> I'm not a computer scientist, and I haven't ever studied multiple
> dispatch, so maybe this is a naive question... but don't you now have
> a problem with cross-coupled sibling dependencies?  Suppose I create
> another type Wild_And_Wooly_Number, derived also from FuzzyNumber?
> How do you fill in your table then?

It is not a naive question. We could say (1) Wild_And_Wooly_Number
knows nothing about SpecialFuzzyNumber. Then a definition of + for any
mixture of SpecialFuzzyNumber and Wild_And_Wooly_Number is not a method
=> not an overriding => either an overloading or illegal. Alternatively
(2) we "just" have to define (no matter implicit or explicit) all
possible combinations involving Wild_And_Wooly_Number and any of
existing successors of FuzzyNumber. If Wild_And_Wooly_Number does not
override +, then the compiler does it implicitly (by taking an
appropritate + where each appearance of Wild_And_Wooly_Number is
replaced by FuzzyNumber). If a programmer overrides at least one, then
there are two possibilities: either to use the default for others (=
unexpected behaviour) or to force the programmer to override all of them
too (= combinatoric explosion).

As I already said in my previous postings, I do not know the answer. I
even do not know whether the answer exists (:-()

--
Regards,
Dmitry Kazakov


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

Re: Parameter Modes, In In Out and Out

[Stephen Leake]

mark_lundquist@my-deja.com writes:

> As near as I can tell, OOP means either (a) class-oriented programming,
> or (b) inheritance (type extension) + polymorphism (dynamic dispatch).

I had hoped to say "OOP is Object Oriented Programming. This means
structuring the code around objects, and using information hiding and
abstraction to enforce the notion of objects".

In that sense, a lot of C code is Object Oriented, and certainly all
of my code is, since my college graduate days.

But in the light of the recent Latin thread, where we learned that
citing the original meaning of words is not relevant, we have take
Mark's statement to mean "It appears that common useage of the term
OOP is either (a) ... or (b)...".

> Class-oriented programming, in my opinion, is a weak concept. But if
> all that is meant is type extentsion and polymorphism, then just as
> you say they are one tool of many in the kit (and not really
> deserving of such a grandiloquent designation as Object Oriented
> Programming).

Agreed.

> That's why I think OOP is such a crummy term.

Perhaps we need a new term, to get back to the original meaning! I'm
stuck on Object Oriented. Any better ideas?

-- 
-- Stephe

Re: Parameter Modes, In In Out and Out

[Robert Dewar]

In article <ud7d1dtiw.fsf@gsfc.nasa.gov>,
  Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:

> I had hoped to say "OOP is Object Oriented Programming. This
> mean structuring the code around objects, and using
> information hiding and abstraction to enforce the notion of
> objects".
>
> In that sense, a lot of C code is Object Oriented, and
> certainly all of my code is, since my college graduate days.

Are you certain you are not confusing objects and OOP with
abstract data types, and programming with ADT's.


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

Re: Parameter Modes, In In Out and Out

[Stephen Leake]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <ud7d1dtiw.fsf@gsfc.nasa.gov>,
>   Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote:
> 
> > I had hoped to say "OOP is Object Oriented Programming. This
> > mean structuring the code around objects, and using
> > information hiding and abstraction to enforce the notion of
> > objects".
> >
> > In that sense, a lot of C code is Object Oriented, and
> > certainly all of my code is, since my college graduate days.
> 
> Are you certain you are not confusing objects and OOP with
> abstract data types, and programming with ADT's.

Well, that is certainly possible; I see ADT's as a good way to
implement objects. In my definition above, I should have said "...
structuring the code around objects in the problem space ..." to
include the notion of real-world objects corresponding to software
objects.

Perhaps I am talking about Object Oriented Design, as opposed to
Object Oriented Programming. I never saw the point in making that
distinction. 

-- 
-- Stephe