Re: SOLVED! Decoupled Mutual Recursion Challenger

[jmartin@oahu.cs.ucla.edu (Jay Martin)]

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