From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,75a8a3664688f227 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-13 10:32:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp.cs.ubc.ca!cyclone.rdc-detw.rr.com!news.mw.mediaone.net!newsxfer.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Parameter Modes, In In Out and Out Date: Sat, 13 Jan 2001 18:22:10 GMT Organization: Deja.com Message-ID: <93q6cd$r3k$1@nnrp1.deja.com> References: <7Cx56.90736$A06.3322588@news1.frmt1.sfba.home.com> <937jab$s23$1@nnrp1.deja.com> <3A57CD7F.2228BFD5@brighton.ac.uk> <938p3u$omv$1@nnrp1.deja.com> <93cagm$c1j$1@nnrp1.deja.com> <93e4e6$ucg$1@nnrp1.deja.com> <93encq$brm$1@nnrp1.deja.com> <93f6ar$m44$1@nnrp1.deja.com> <93flab$2mh$1@nnrp1.deja.com> <93fqau$6m2$1@nnrp1.deja.com> <93h9mo$bbm$1@nnrp1.deja.com> <93il87$iqo$1@nnrp1.deja.com> <93k6dv$qt6$1@nnrp1.deja.com> <93ko49$auq$1@nnrp1.deja.com> <93modu$36k$1@nnrp1.deja.com> <93n2co$alq$1@nnrp1.deja.com> <93q39q$oq0$1@nnrp1.deja.com> NNTP-Posting-Host: 205.232.38.14 X-Article-Creation-Date: Sat Jan 13 18:22:10 2001 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x65.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:3991 Date: 2001-01-13T18:22:10+00:00 List-Id: In article <93q39q$oq0$1@nnrp1.deja.com>, dmitry6243@my-deja.com wrote: > In article <93n2co$alq$1@nnrp1.deja.com>, > Robert Dewar 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/