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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-27 21:46:14 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!delphi.cs.ucla.edu!not-for-mail From: jmartin@oahu.cs.ucla.edu (Jay Martin) Newsgroups: comp.lang.ada,comp.object Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger Date: 27 Oct 1994 21:28:41 -0700 Organization: UCLA Computer Science Dept. Message-ID: <38pulp$ovg@oahu.cs.ucla.edu> References: <1994Oct18.221751.15457@swlvx2.msd.ray.com> <38289r$79m@oahu.cs.ucla.edu> <1994Oct19.143843.372@wdl.loral.com> <38fi4r$l81@oahu.cs.ucla.edu> <1994Oct24.174231.1897@swlvx2.msd.ray.com> <38hcv3$j85@baleen.cs.ucla.edu> <1994Oct25.155420.27353@swlvx2.msd.ray.com> NNTP-Posting-Host: oahu.cs.ucla.edu Keywords: Ada9X, "withing" problem X-Newsreader: NN version 6.5.0.b3.0 #8 (NOV) Xref: nntp.gmd.de comp.lang.ada:16253 comp.object:16713 Date: 1994-10-27T21:28:41-07:00 List-Id: jgv@swl.msd.ray.com (John Volan) writes: >jmartin@baleen.cs.ucla.edu (Jay Martin) writes: >>(Can't do anything other than rant now (got to fix bugs)) Jay. > ^^^^ ^^^^^^^^^^^^^^^ Oops, I was trying to say that, I was under time pressure to get something done and couldn't fully analyze your post but was going to respond later. Instead I took a nasty swipe at CS (I am a CS PHD student). You think my last post was bad.... >>>Don't underestimate the complexities involved here. Your "package >>>forward" idea is essentially identical to the "package abstract" >>>concept I suggested a while back (although my proposal didn't require >>>any new Ada reserved-words :-). When I presented the idea of "package >>>abstracts", I at least considered some of the issues they raise: >>>1. Is a package abstract an optional feature, or are you compelled to >>> precede every package spec with a package abstract? If optional, >>> how do you distinguish a package spec that has a preceding abstract >>> from one that does not? Or are we creating a situation analogous to >>> the Ada83 problem of an "optional body for a bodiless package spec"? >>>2. How do you distinguish a "with"-clause that only imports a package >>> abstract from one that imports the whole package spec? >>>3. Can a package-with-abstract be generic? If so, where does the generic >>> clause go? How do you instantiate such a beast? What impact does this >>> have on the whole generic contract scheme? >>>4. This is much too late for 9X, and has to be left for 0X, if it goes >>> anywhere at all. Even if all the difficulties can be ironed out, is >>> this feature worth the added compiler complexity, when there are >>> reusable workarounds that already effectively extend the language? >>1. Optional, No, No. >>2. No. >"NO"? What's the point of having two outside views of a package (one >incomplete, the other fuller) if a potential client can't select how >much of a view they want? (Do you even have a *clue* what I'm talking >about, Jay?) Since, I specified that only thing a package "forward" could contain is an incomplete type or a pointer type to one of these incomplete types. Such alternate views would be pretty much useless for forwards. Only thing the package forward does is stop the compiler from giving errors for types that are going to be declared. The same sort of thing could probably also be done by "type forward OtherPackage.AType;" shoved into the spec of dependent mutually recursive type. Its saying "hey" I am going to declare this type later in the other package don't kill my compile. Of course we could depend on a complex compilation system to solve all these mutually recursion problem, but forward is more in accordance with the simple Ada model of compiling in dependency order. I thought I heard cross-package incomplete types in the early days of Ada9X? (Probably dropped) >>3. No. >Why not? Why do we have to make a *special exception* in this case, >for a feature that ought to be *orthogonal* to this? Is it just >because someone like you doesn't want to be bothered about thinking >things through? Orthogonality is crap. It used as a excuse, "well we have this feature so we must have this feature. This feature has to be seemlessly integrated with that feature and we need this other feature to do it! Hey we can throw in this capability for almost free!". A programming language is like the budget for the US government. You can only throw in so much complexity until the implementation gets huge and learning curve start to overwhelm the programmer, thus going over budget. You can borrow money and go over the budget but you'll have to pay for it eventually when your obese language has to evolve. You got to cut sometimes even if the features are important and useful. Language design is also like the Vietnam war, each small step was rational and reasonable in a micro perspective but the overall result ends up irrational. Anyway, if your language is getting so complex and obscure that you need hundreds of people to work out the details, then I believe that the language has crossed the boundry of reasonableness. How is a programmer ever going to understand such things. I believe simplicity is possible. Simplicity of course has costs. Don't confuse non-orthogonality with PL1 (the typical example), if IBM had made PL1 completely orthogonal it still would have been crap! Exceptions rule! Cut the budget! In my opinion, the first reaction to whether an arbitrary feature A "package forward" works with feature B "generic packages" should be no. The compiler can just say "package forwards cannot be generic (RM5.2.23.3)". We can not just make the argument, due to orthogonanlity.... We must weigh whether it is worth the extra complexity/danger given typical usage. Likewise, we shouldn't say that "We can't add that feature because due to orthogonality, it implies this, this and this must be inserted which makes the original proposal too obese". Okay, okay some substance. It seems more reasonable for generic mutual recursive objects to be in the same generic unit this is because I assuming the we want to instantiate the generics with the same generic parameters. For example: generic ... package Holder is package forward X ...; package Y ...; package X ...; end Holder; Of course we may want to have each of the mutually recursive generic packages be separately compiled. The problem is that we can't reference a generic package because it may have multiple instances. (Unlike C++'s TemplateType<> which can only have one template instance per template parameter combination). This implies that the mutual recursive package types must be passed in the generic parameters themselves. Thus we can use the "forward" idea in the following way. We define generic versions of the package and achieve mutual recursion in the following way. package forward X is new XGen; -- Incomplete generic instatiation. package Y is new YGen(X.XType,...); package X is new XGen(Y.YType,...); So, I think the answer to, Can there be forward packages that are generic? is still NO. I know this is probably got tons of flaws and so I will have analyze this more fully after I read the Ada9x manuals this weekend. (Time pressure again) >>4. Who cares. If the standard can't be easily modified as was the >> case for Ada83 then Ada9x is dead. >"Easily modified"? Do you think what the MRT has been doing these >past few years was *easy*? Where have you *been*? Do you have >*any* idea about what it takes to revise an *international standard*? The standards community is basically full of shit with respect to computer languages and should be destroyed. Look at the FORTRAN standardization process it was essentually politically gridlocked producing nothing for 20 years. The only thing that is holding C++ together is the brilliance and leadership of Stroustrup. Imagine if some committee designed C++ from scratch, it would have been worthless joke. Ada83 was just handed over to the international standardization organization and said, "Check the spelling and ratify it". This, in my opinion, is the only way that languages should be standardarized. Ada83 has been ruined because it has been set in cement with even minor changes impossible. Why? Standards! Don't you love em! What the DOD should have done is kept Ichbiah and CO. in a cage (with lots of money) and had him modify Ada as was necessary over the last 12 years. Language design is maintanance! So it is trivially obvious that the only way to do language design and maintanance is to have one reasonable,dedicated and responsible individual have total power and control (The IQ of a committee...). (Wirth the only Computer Scientist to make a widely used language fails the dedicated and responsible criteria). >> The Compiler complexity is trivial, >> the language would be cleaner. >"Cleaner"? With yet another language feature to complicate things? I >don't think it would be the *language* that would be "cleaner". The >*programs* written in that language would be (a tad) "cleaner", at the >expense of (possibly a lot) more complexity in the language. Or >rather, a certain very particular *style* of programs would be >"cleaner", possibly at the expense of other styles of programming. Cleaner is is what cleaner does. >I'm not a language lawyer, and I've never written a compiler, so I >haven't presumed to make any claim as to how "trivial" this kind of >feature would be. At most, I've tried to point out a few of the >conceptual difficulties I could see, but that's all speculation on my >part. Maybe it *is* "trivial", and if so, I hope some experienced >language lawyers will pipe up and say so. Even if it isn't trivial, >maybe it's worth it anyway -- and if so, I hope some language lawyers >will pipe up about that too. But for now, I'm reserving my judgment. >Jay, are *you* a language lawyer? Have *you* ever written an >industrial-strength compiler? That's not a rhetorical dig. If you've >got some real experience here, by all means say so. But somehow I >doubt it, since your organization seems to be a university computer >science department, and I suspect you are a student. Like all lawyers, language lawyers should be shot. :-) Sorry, real language design and implementation are not worthy of study in Computer Science (I heard a rumor that this is what Stanford said to Wirth when they gave him the boot), so I have not worked on or likely to work on languages of the size, generality and seriousness of Ada9x or C++. Actually the bugs I am working on are in a compiler for an concurrent language. If the forward idea is not "orthogonalized" to include everything and the kitchen sink. Then it would be simple to play with the parser to except them. A new object type would have to be added to ada libraries (besides spec and body). On withing a package spec if the real spec had not yet been compiled the incomplete type symbols would be read into the symbol table. A simple check at link time for missing specs and ta da! >>Ada9x is too obese and is being too effected [sic] by trying to be an >>"elegant" (rigid) extension of obese Ada83. >One man's "elegant" is another man's "rigid." Is C++ an "elegant" >extension of C, or is it "rigidly" preserving C's syntax, which many >(even in the C/C++ camp) have disavowed as obsolete and kludgy? (For >goodness sake, even *Bjarne Stroustrup* seems to have chafed a bit >about C syntax -- but I won't presume to speak for him.) Is C++ still >"lean and mean" today, or is the agglomeration of new features such as >templates, exceptions, first-class bool and string types, and >namespaces, (all of which were in Ada ten years ago) turning it into >an "obese" language? Is Eiffel "elegant" because of its minimalist >design, or is it "rigid" because it offers only "One True Way" of >modularizing a program, and has to resort to auxiliary languages such >as LACE to deal with higher levels of organization? The only way to elegantly extend C is with a nuclear weapon. C++ is obese. Eiffel is less obese but still pretty fat. I was not that impressed by the original Eiffel. I am sure "Eiffel 3000" has probably fixed alot of these problems, but I haven't looked at the new version. Ada9x design is rigid because it tried too hard to extend Ada existing features. Maybe it should have just thrown in the towel on derived types, depreciated private types, kept packages as containers and added a "class" construct. >>I really don't understand >>why can't some clown ... > ^^^^^ >Let's see, from now on we'll have all our programming languages >designed by Bozo and Ronald MacDonald, and maybe a few Congressmen, >too... One clown is all that is needed and would get better results than any committee. (I am writing this on bozo.cs... so I vote for Bozo!) >>... spend a few minutes ... > ^^^^^^^^^^^^^ >Is that how long K&R spent designing C? Might explain a lot ... Come on, it took them at least an hour not counting the hour they beat each other in the head with baseball bats to obtain the necessary idiocy to produce C! C is brilliant work of CS! Designing a language? Don't know which way to do something? Doing the opposite from C pretty much guarantees you got it right. >> ... to come up with a cleaner >>smaller (more minimalist) Ada style language. >... as long as your own "trivial" pet language construct gets into it? >Honestly, do you really think that language designs can just be >slapped together, or that you can just slap in yet another feature >without causing a ripple effect in the whole design of a language? It >seems to me that *that* way leads to *larger*, *more complex*, *less >cohesive* languages, NOT "smaller, more minimalist" languages. See anti-orthogonality arguments above. >Of course, if you so vehemently believe that this *is* such a >trivial feature to slap on top of Ada9X, then I suggest that you >get yourself a copy of GNAT, revise it to implement your new >language feature, experiment with it, and then write a learned >treatise on just how trivial and orthogonal it is (or isn't, >as you might just discover). Put up or shut up. Huh? Oops, by "Ada style language" I meant a completely different language without upward compatibility problems. Remove tasking, exceptions, nesting, floating point types, discriminated records, derived types, real models, fixed point types, blocks, goto, named parameters, aggregates, slices, rep clauses, simplify generics,etc, you can gain alot of simplicity. >>My theory of why CS is > ^^^^^^ >>not coming up with one is: (1) Most Computer Scientists are >>masturbating on useless theoretic, pseudo "huge breakthroughs" and > ^^^^^^^^^ >>"scientific" things. >Oh, I see. It's okay for *you* to have your pet theories, but nobody >else's ideas are worth pursuing. Whatever's "trivial" according to >*your* theories are nuggets of wisdom to be enshrined, but if anybody >*else* has an opposing view of what's important for software >engineering, that's "pseudoscience." >Maybe your jaundiced view about "Computer Science" has less to do with >the state of the software engineering *industry* and more to do with >the state of *academic* computer science -- or maybe it just says more >about the particular academic *institution* you're currently part of. >If the latter is the case, then I feel sorry for you, and suggest you >transfer immediately to another school. I am talking about academic computer science (what else is there). And you are right, no one here really gives a rats ass about programming, software engineering or SE language design. There currently not even one class being taught about Software Engineering at my university (not this year or last) Ada isn't even on our CS dept computer, C++ probably wouldn't be if it didn't automatically come with GCC. In my opinion, the priests of Computer Science don't care much about Software Engineering, its pretty much an orphan field in academia. Look at some CS journals or thesis/tech reports from CS departments to see some really useless theoretical nonsence. I have a vision of Computer Science acting as the "powerful tugboat" pulling the ocean liner "Software Industry" through the stormy waters. The truth is more like ocean liner "Software Industry" is pulling a tiny dingy with passenger Computer Science performing unspeakable masturbitorial acts. Lucky the rope used to tow the dingy is miles long so that the passengers on the ocean liner don't have to view this disgusting behavior! Why is this important to Ada? Because I don't think industry is ever going to start using Ada or any elegant SE language. Maybe if the colleges (which theoretically are more purist) supported Ada then it would take off. But sadly I don't see much hope there either. >>Language design requires them to sink into the >>abyss of unholy "social science" and the law of the lowest common > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>denominator. > ^^^^^^^^^^^^ >I understand it all now. Forget striving for excellence, folks! Don't >bother! Let's just keep things at the level where any fool can slap >software together! Sure, only a fool would buy or use such software, >but that's okay, because *everybody* would be equally foolish. O >Brave New World ... My theory of computer language design is this: Programmers are idiots, assholes and pinheads. Since I am a programmer, I am a pinhead too. Look what I wrote in a boolean expression in C today: BoolVar = (IntVar =! 2);. I wanted "!=" not "=!". So what did C do for me instead of giving a compiler error: (1) It conceptually converted 2 into a boolean True and (!) not-ed it to False. Implicit type conversion rules! (2) Converted the Boolean False to an integer 0 and assigned it to IntVar. IntVar is trashed. I never imbedded assignments especially not in boolean expressions, I did today! (3) The assignment convieniently returned a copy of the new value of IntVar, which was converted to a boolean and assigned to my boolean variable. Yahoo. C gave me the power and flexiblity to make an embarassing mistake. ----------- If you design a language that requires 200 IQ brainos who never make errors to understand/use, then trying to use that language on a project of a hundred average programmers is not going to be successful. Thus language design must be down to earth, understandable and safe for the average programmer. Spaced out grandious languages is not what software developers need. I am not saying this languages shouldn't be researched but practical designs must also be studied. >>(2) Even if one did, political jealousy and power games >>within the Computer Science community would not allow them to >>recognize, except [sic], support and then champion a really good and >>software engineering efficient language. >"Let him who is without sin ..." In my experience, those who >whine most about "political jealousy" and "power games" are usually >those who *tried* to play political power games in the past and >*failed*. Never tried. Never will. Politics both facinates and repulses me at the same time. Can they really be that stupid/self centered? Yup, the CS community is rolling out the ol red carpet for Ada since 1983. And they are screaming and yelling how great Eiffel is. My opinion is that no endorsements are allowed as they are "too political" and non-scientific. Of course, social science programming experiments could be performed to prove that certain language styles are more SE efficient than others but this might step on some toes and besides its obvious and boring. I want CS to be out in front AND practical in the field of language design. They should be defining language design, not ignoring it. Computer Science has been pretty much failures at producing practical computer languages. My theory is that this political climate exists, thus causing no academic work to be carried out. I get the feeling that if I proposed to do a language for my thesis, they would laugh, "Where is the science?". Jay.