Re: SOLVED! Decoupled Mutual Recursion Challenger

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

jmartin@oahu.cs.ucla.edu (Jay Martin) writes:

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

Re-reading your post a little more closely, I realize now that we may be
more in agreement than I initially thought.  Therefore, I humbly apologize
for the flame.  (However, the tone of your posts is pretty inflammatory ...
might I suggest cooling it off a bit?)

[snip]

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

The intent of my package "abstracts" was to allow exactly that kind
of thing (temporary tolerance for "incomplete" declarations), and in
fact, that's the "alternate view" that I was talking about.

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

But this buries an inter-module dependency within a special kind of
type declaration that could then appear anywhere within a package.  How
about just leaving the issue of inter-module dependencies to context
clauses, where they've always been?  In other words, why couldn't we
have something like:

    with abstract of Employee;
    -- Only imports the abstract of package Employee, providing only
    -- incomplete views of some object types, plus some access types
    -- (i.e., whatever we actually put in the abstract).

versus:

    with Employee;
    -- Imports the full package spec of Employee as well as the abstract
    -- (if there is one), and so provides complete views of all types 
    -- declared publicly (and anything else declared there).

I think that your "package forwards" are pretty close to my "package
abstracts", but some of the details that you propose seem more ad-hoc,
given the design of Ada.

>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)  

If so, it was probably for good reasons.  Unfortunately, it doesn't
look like anyone fought to find an alternative that could avoid those
problems (whatever they were).  Maybe the package abstracts concept
is a step closer to that ideal alternative.  I don't know.

>>>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!".  

Orthogonality is not an excuse to add ad-hoc features.  Done right, it
can simplify the design of a language, and *reduce* the need for
ad-hoc features.  But to do it right, the features have to be cast in
such a way as to be truly orthogonal to each other, and thus truly
*composable*.  If you do find that you have to add ad-hoc special
cases and restrictions when you try to compose features that were
supposed to be orthogonal, it may be a sign that the way you split up
the language is flawed.

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

Or perhaps there is third alternative: Perhaps we can formulate the
new feature in such a way that does not disturb the old features and
does not require a special-case restriction.  And perhaps, formulated
that way, the new feature can turn out to be extremely powerful for
many uses beyond those it was initially conceived for.  Perhaps the
"new" feature could even turn out to be just the thing that was needed
to *simplify* the whole design of the language, as well as the
compilers that support the language.  However, achieving something
like that requires a lot of deep thought and perhaps some research. It
cannot be slapped in on the spur of the moment.

[snip]

>Yahoo.  C gave me the power and flexiblity to make an embarassing 
>mistake. 

Interesting C bug.  But I would argue that this just shows that C's
"orthogonality" is "orthogonality done *wrong*".

[snip]

					John G. Volan

--------------------------------------------------------------------------------
--  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.");
--------------------------------------------------------------------------------