Re: SOLVED! Decoupled Mutual Recursion Challenger

[jgv@swl.msd.ray.com (John Volan)]

mbk@inls1.ucsd.edu (Matt Kennel) writes:

>Jay Martin (jmartin@baleen.cs.ucla.edu) wrote:

>: Ada9x is too obese and is being too effected by trying to be an
>: "elegant" (rigid) extension of obese Ada83.  I really don't understand
>: why can't some clown spend a few minutes to come up with a cleaner
>: smaller (more minimalist) Ada style language.

>That's what Meyer did, it's called Eiffel.  Really.  Ada83 was a big
>influence.

Eiffel is nice.  I like Eiffel.  But is Eiffel really enough?  Why does
Eiffel need LACE to prop it up, for instance?

>Absent this, the problem here in 9x can be "solved" by a nearly transparent
>change to the language:  say "cyclic dependencies in types, but not
>initialization expressions, are now allowed."  like
>it always should have been, in my opinion.

I dispute that this is a "nearly transparent" change to the language.
Other folks have already pointed out to you that Ada's
order-of-declaration dependencies reflect an underlying assumption
about declarations: They all get *elaborated* at run-time, in a
specific order.  That is, every declaration "takes effect" at a
specific point in time during execution, and this might (or might not,
as the case may be) cause something to occur at run time (such as
initialization).  This rule applies to *all* declarations in Ada,
including variable declarations, type declarations, subprogram
declarations, package declarations, what have you.

Your answer to this seems to be: "Well, let's single out one kind of
declaration -- type declarations -- as a *special case* that totally
violates that general rule, just to make one particular style of
programming easier, or to make Ada more closely resemble somebody
else's pet language.  Go ahead and refer to types that haven't been
declared yet -- even types from other packages that haven't been
*compiled* yet. We don't really care who gets elaborated first ..."

IMHO, that road leads to madness.  If you establish broad language
design principles, but then overrule them for special cases at every
turn, you wind up with a recipe for a bloated, complex, and incoherent
language.  No thank you.  A lot of the additional power in Ada9X over
Ada83 has arisen as a direct result of *broadening* the application of
Ada's original principles, *eliminating* special-case situations, NOT
adding new ones.

>Now you can declare an X which has a component of type/package/class/whatever
>Y, and have Y which has a component of class X.

"Type/package/class/whatever"????  Again, you're conflating all these
things to be the same thing, as if Ada were Eiffel.

>It's not transparent to the compiler implementors, but no fix
>here would be.

Of course.  But I would rather live with "package abstracts" than
"automagically forwarded types."

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------