Re: Parameter Modes, In In Out and Out

[Robert Dewar <robert_dewar@my-deja.com>]

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/