'withing' problem

'withing' problem

[David Crocker]

Are there any commercial compilers with language extensions to work around
the infamous "withing" problem?

We have a tool that generates (currently) C++ or Java code from precise
specifications and we would very much like to generate Ada95 as well so we
can better target safety-critical applications. But because our tool
encourages an object-oriented style, any attempt at code geenration in Ada
usually falls foul of the withing-problem very quickly (we can't even
compile the runtime library without hitting the problem).

I am aware of the woraround described at
http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html but I doubt this
would be acceptable in a safety-critical application. I am also aware that
GNAT implements a workaround, but what we really need is a validated
compiler.

I heard that the next update to the Ada language circa 2005 will address the
problem, but this is too far away to be any consolation. Surely we can't be
the only company that needs the problem fixed urgently? How do the
developers of large military software systems manage?

Regards

David Crocker, Escher Technologies (www.eschertech.com)

Re: 'withing' problem

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "David Crocker" <dcrocker@imsltd.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: November 02, 2001 4:24 AM
Subject: 'withing' problem


> Are there any commercial compilers with language extensions to work around
> the infamous "withing" problem?
<snip>
Isn't GnatPro a commercial compiler? and validated?

Re: 'withing' problem

[Robert Dewar]

"David Crocker" <dcrocker@imsltd.com> wrote in message news:<3be27344$0$227$ed9e5944@reading.news.pipex.net>...
> Are there any commercial compilers with language 
> extensions to work around the infamous "withing" problem?

Yes, GNAT Pro implements a version of the "with type" proposal that
was made some time ago to solve this problem.
 
> I am also aware that GNAT implements a workaround

This is not a "work around" but rather a language extension
feature that directly addresses the problem.

> but what we really need is a validated compiler

The presence of extensions in a compiler does not mean the
compiler cannot be validated, providing that there is a way
to turn off the extensions, as is the case with GNAT Pro.

> I heard that the next update to the Ada language circa 
> 2005 will address the problem, but this is too far away 
> to be any consolation. Surely we can't be
> the only company that needs the problem fixed urgently?

The only way to have an "urgent" fix to this problem is
to go with implementation extensions of the kind in GNAT
Pro. Yes, they won't be fully portable to other compilers,
but there is no immediate urgent short term solution that
will solve that. Note that the ARG is still discussing the
preferred long-term solution, and has recently been examining entirely
different approaches. The sequence of
events is that first the ARG approves a detailed proposal,
the WG2.1 approves it, then it appears in an official
addendum. Even the first step is a way off, and so I do not
expect vendors to be implementing a common solution anytime
soon, and indeed, even if the ARG does approve a solution,
that is no guarantee that any vendor will implement it on
any particular time schedule.

> How do developers of large military software systems 
> manage?

Well at least for our customers, they use the feature we
have provided in GNAT Pro. This feature was not implemented
for our amusement, but rather in response to serious customer needs.

Robert Dewar
Ada Core Technologies

Re: 'withing' problem

[Wes Groleau]

David Crocker wrote:
> Are there any commercial compilers with language extensions to work around
> the infamous "withing" problem?
> 
> GNAT implements a workaround, but what we really need is a validated
> compiler.

You can't have such a language extension AND a
validated compiler in the same invocation.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: 'withing' problem

[Ted Dennison]

In article <3be27344$0$227$ed9e5944@reading.news.pipex.net>, David Crocker
says...
>the only company that needs the problem fixed urgently? How do the
>developers of large military software systems manage?

Mutual dependancies of this sort in my book are a classic sign of a sloppy
design. Thus we cope with this problem by cleaning up our design when this
happens.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: 'withing' problem

[Ed Falis]

Ted Dennison wrote:
 
> Mutual dependancies of this sort in my book are a classic sign of a sloppy
> design. Thus we cope with this problem by cleaning up our design when this
> happens.

I believe the original poster said he was moving (automatically?) code
from a language such as Java to Ada, where the lack of spec and
implementation separation leads naturally to mutually dependent
classes.  In such languages, this is not necessarily bad design.

- Ed

Re: 'withing' problem

[Preben Randhol]

On Fri, 02 Nov 2001 17:19:17 GMT, Ed Falis wrote:
> I believe the original poster said he was moving (automatically?) code
> from a language such as Java to Ada, where the lack of spec and
> implementation separation leads naturally to mutually dependent
> classes.  In such languages, this is not necessarily bad design.

No, but either moving code automatically or not, one ought to redesign
in Ada in order not to get into this problem with withing. I find it an
odd approache to change the language you are moving code *to* in order
to fit features in the language one is moving the *code* from! The code
should change not the language.

Preben Randhol
-- 
Please, stop bombing civilians in Afghanistan. One cannot write off
killing innocent children and other civilians as "collateral damage".
A civilian is a civilian whether he or she is American or from another
country in the world.           http://web.amnesty.org/11september.htm

Re: 'withing' problem

[Ed Falis]

Preben Randhol wrote:

> No, but either moving code automatically or not, one ought to redesign
> in Ada in order not to get into this problem with withing. I find it an
> odd approache to change the language you are moving code *to* in order
> to fit features in the language one is moving the *code* from! The code
> should change not the language.

If you're using one of the JBC targeted Ada compilers it makes a lot of
sense; otherwise your point stands.  Besides, my comment was about
design in those other languages being sloppy or not, independent of any
port to Ada.

- Ed

Re: 'withing' problem

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

>> Are there any commercial compilers with language extensions to work around
>> the infamous "withing" problem?

> Isn't GnatPro a commercial compiler? and validated?

In almost all cases, you do not want to use GNAT in the dynamic
elaboration model mode, which is required for standard
conformance.

In non-standard mode, a compiler is allowed to do anything.  For
example, there's a non-standard mode available with most GNAT
installations which compiles C programs instead of Ada programs. ;-)

Re: 'withing' problem

[DuckE]

I believe you'll find in the original post that the intent is not to "move
code"
but rather to support another language with a program generation
tool.

SteveD

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9u5sln.v0j.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Fri, 02 Nov 2001 17:19:17 GMT, Ed Falis wrote:
> > I believe the original poster said he was moving (automatically?) code
> > from a language such as Java to Ada, where the lack of spec and
> > implementation separation leads naturally to mutually dependent
> > classes.  In such languages, this is not necessarily bad design.
>
> No, but either moving code automatically or not, one ought to redesign
> in Ada in order not to get into this problem with withing. I find it an
> odd approache to change the language you are moving code *to* in order
> to fit features in the language one is moving the *code* from! The code
> should change not the language.
>
> Preben Randhol
> --
> Please, stop bombing civilians in Afghanistan. One cannot write off
> killing innocent children and other civilians as "collateral damage".
> A civilian is a civilian whether he or she is American or from another
> country in the world.           http://web.amnesty.org/11september.htm

Re: 'withing' problem

[Simon Wright]

Ted Dennison<dennison@telepath.com> writes:

> In article <3be27344$0$227$ed9e5944@reading.news.pipex.net>, David Crocker
> says...
> >the only company that needs the problem fixed urgently? How do the
> >developers of large military software systems manage?
> 
> Mutual dependancies of this sort in my book are a classic sign of a
> sloppy design. Thus we cope with this problem by cleaning up our
> design when this happens.

If you are coming from a UML-based modelling environment,
cross-dependency is entirely natural. It would be quite wrong to
contort the model to cope with Ada's unfortunate limitations in this
respect.

WITH TYPE (or equivalent) is a very natural way for the software
architecture to support this requirement (provided your independent
safety advisor will let you).

Without the compile-time type checking that WITH TYPE gives you, you
are likely to end up with (some) run-time checks which is a Bad Thing
if it can be avoided.

Re: 'withing' problem

[Simon Wright]

"David Crocker" <dcrocker@imsltd.com> writes:

> I am aware of the woraround described at
> http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html but I doubt this
> would be acceptable in a safety-critical application. I am also aware that
> GNAT implements a workaround, but what we really need is a validated
> compiler.

It's quite possible that a compiler supporting WITH TYPE might pass
the ACATS suite. However, I suspect there's something that has to be
signed saying that there are no deliberate extensions!

Re: 'withing' problem

[Simon Wright]

"David Crocker" <dcrocker@imsltd.com> writes:

> We have a tool that generates (currently) C++ or Java code from
> precise specifications and we would very much like to generate Ada95
> as well so we can better target safety-critical applications. But
> because our tool encourages an object-oriented style, any attempt at
> code geenration in Ada usually falls foul of the withing-problem
> very quickly (we can't even compile the runtime library without
> hitting the problem).

We have exactly this problem! (though I'm surprised at your difficulty
compiling the runtime library? which library is that?)

> I am aware of the woraround described at
> http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html but I
> doubt this would be acceptable in a safety-critical application.

I guess you need to talk to your safety guys about this one. Of
course, it must depend on the criticality. If your system is SIL4 (UK
speak) you'll have a raft of tool chain problems if you go for
automatically generating code, won't you?

-- 
Simon Wright                       Work Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                        Voice: +44(0)23-9270-1778
Integrated Systems Division                     FAX: +44(0)23-9270-1800

Re: 'withing' problem

[Preben Randhol]

On Sat, 03 Nov 2001 02:52:58 GMT, DuckE wrote:

> I believe you'll find in the original post that the intent is not to
> "move code" but rather to support another language with a program
> generation tool.

Well then the generation tool should be changed to support Ada propperly :-)

Preben Randhol
--
�.., chaos is found in greatest abundance wherever order is being
sought. It always defeats order, because it is better organized.�
                            -- Interesting Times, Terry Pratchett

Re: 'withing' problem

[Richard Riehle]

Simon Wright wrote:

> If you are coming from a UML-based modelling environment,
> cross-dependency is entirely natural. It would be quite wrong to
> contort the model to cope with Ada's unfortunate limitations in this
> respect.

Funny.  I don't regard the current context clause (with) as a problem,
when one is designing in Ada.    It is most certainly not an "unfortunate
limitation."    Rather, the grumbling about it most often reflects a lack
of understanding, or acceptance, of the very strict visibility rules of
the language.   As to the potential for circular context clauses, these
need not exist when one correctly designs in Ada.

When I first learned Ada, what seems now many lifetimes ago, I was
annoyed by the recurring errors I would have due to visibility issues.
The compiler kept bothering me with nasty messages about this.  In
time, I came to appreciate that one of Ada's primary strengths is in
is separation scope and visibility.   Now I realize that those visibility
rules are essential in reasoning about good design.

More Ada programmers have problems with visibility rules than with
any other feature of the language.   Some will go for years, designing
and coding in Ada, and never come to terms with the visibility rules.
I am reminded of first learning to use a rotating brush floor buffer for
a part-time job in high-school.  The brushes rotate over the floor in
their own way.   When I struggled to overpower the rotating brushes,
I could not succeed.   Once I learned how to balance the brushes
lightly, and guide them across the floor according to their own
behavior, I could control the machine with one finger.   Struggling
with the context clause and visibility rules is much the same.  Learning
to use those rules, they make the Ada software design
process easy and fun.  Try to defeat them and the process is
hard and unpleasant.

Richard Riehle

Re: 'withing' problem

[Simon Wright]

Richard Riehle <richard@adaworks.com> writes:

> Simon Wright wrote:
> 
> > If you are coming from a UML-based modelling environment,
> > cross-dependency is entirely natural. It would be quite wrong to
> > contort the model to cope with Ada's unfortunate limitations in this
> > respect.
> 
> Funny.  I don't regard the current context clause (with) as a
> problem, when one is designing in Ada.  It is most certainly not an
> "unfortunate limitation."  Rather, the grumbling about it most often
> reflects a lack of understanding, or acceptance, of the very strict
> visibility rules of the language.  As to the potential for circular
> context clauses, these need not exist when one correctly designs in
> Ada.

Well, you see, I'm not at all sure one should be "designing in Ada".

If your project was going to implement in C++, would you design in it?

Do you think that software designed with mutual dependency is less
reliable? less safe? more expensive? If there's a compelling argument,
OK, otherwise I stand by "unfortunate limitation".

Re: 'withing' problem

[David Crocker]

OK, so if you think cross-dependency reflects bad design when the
implementation language is Ada, can you tell me how you would redesign the
Doctor/Patent/Insurer example in
http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html ?

Or, take this example from compiler technology. There are various sorts of
statement in a programming language, so there is a heirarchy of Statement
classes. Similarly, there are various sorts of expression, so there is a
heirarchy of Expression classes. Some types of statement can contain
expressions, so the Expression class heirarchy needs to be visible within
the the declaration of these statements classes. Similarly, some of the
Expression classes need to know about statements (e.g. conditional
expressions are turned into conditional statements prior to code
generation). So we immediately have a cross-dependency. I can then throw a
Declaration class heirarchy into the picture and it becomes a 3-way
cross-dependency.

I should explain that my background is OO design, not Ada. Maybe Ada 95
should not really claim to support object-oriented development? (although it
was the first object-BASED language in widespread use).

The context here is that we have a OO-based formal methods tool that could
make the development of safety-critical software much more productive, but
we will either have to compile down to machine code, or find a suitable
back-end compiler we can target. Currently we generate C++ and Java, but Ada
appears to be the natural choice for the safety-critical market.

David Crocker, Escher Technologies Ltd. www.eschertech.com


"Richard Riehle" <richard@adaworks.com> wrote in message
news:3BE42900.7590E899@adaworks.com...
> Simon Wright wrote:
>
> > If you are coming from a UML-based modelling environment,
> > cross-dependency is entirely natural. It would be quite wrong to
> > contort the model to cope with Ada's unfortunate limitations in this
> > respect.
>
> Funny.  I don't regard the current context clause (with) as a problem,
> when one is designing in Ada.    It is most certainly not an "unfortunate
> limitation."    Rather, the grumbling about it most often reflects a lack
> of understanding, or acceptance, of the very strict visibility rules of
> the language.   As to the potential for circular context clauses, these
> need not exist when one correctly designs in Ada.
>
> When I first learned Ada, what seems now many lifetimes ago, I was
> annoyed by the recurring errors I would have due to visibility issues.
> The compiler kept bothering me with nasty messages about this.  In
> time, I came to appreciate that one of Ada's primary strengths is in
> is separation scope and visibility.   Now I realize that those visibility
> rules are essential in reasoning about good design.
>
> More Ada programmers have problems with visibility rules than with
> any other feature of the language.   Some will go for years, designing
> and coding in Ada, and never come to terms with the visibility rules.
> I am reminded of first learning to use a rotating brush floor buffer for
> a part-time job in high-school.  The brushes rotate over the floor in
> their own way.   When I struggled to overpower the rotating brushes,
> I could not succeed.   Once I learned how to balance the brushes
> lightly, and guide them across the floor according to their own
> behavior, I could control the machine with one finger.   Struggling
> with the context clause and visibility rules is much the same.  Learning
> to use those rules, they make the Ada software design
> process easy and fun.  Try to defeat them and the process is
> hard and unpleasant.
>
> Richard Riehle
>
>

Re: 'withing' problem

[David Crocker]

Thanks for that, I didn't realise that Gnat Pro was used for critical
applications. I will investigate it further.

Regards

David Crocker www.eschertech.com

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111020649.4c0f973f@posting.google.com...
> "David Crocker" <dcrocker@imsltd.com> wrote in message
news:<3be27344$0$227$ed9e5944@reading.news.pipex.net>...
> > Are there any commercial compilers with language
> > extensions to work around the infamous "withing" problem?
>
> Yes, GNAT Pro implements a version of the "with type" proposal that
> was made some time ago to solve this problem.
>
> > I am also aware that GNAT implements a workaround
>
> This is not a "work around" but rather a language extension
> feature that directly addresses the problem.
>
> > but what we really need is a validated compiler
>
> The presence of extensions in a compiler does not mean the
> compiler cannot be validated, providing that there is a way
> to turn off the extensions, as is the case with GNAT Pro.
>
> > I heard that the next update to the Ada language circa
> > 2005 will address the problem, but this is too far away
> > to be any consolation. Surely we can't be
> > the only company that needs the problem fixed urgently?
>
> The only way to have an "urgent" fix to this problem is
> to go with implementation extensions of the kind in GNAT
> Pro. Yes, they won't be fully portable to other compilers,
> but there is no immediate urgent short term solution that
> will solve that. Note that the ARG is still discussing the
> preferred long-term solution, and has recently been examining entirely
> different approaches. The sequence of
> events is that first the ARG approves a detailed proposal,
> the WG2.1 approves it, then it appears in an official
> addendum. Even the first step is a way off, and so I do not
> expect vendors to be implementing a common solution anytime
> soon, and indeed, even if the ARG does approve a solution,
> that is no guarantee that any vendor will implement it on
> any particular time schedule.
>
> > How do developers of large military software systems
> > manage?
>
> Well at least for our customers, they use the feature we
> have provided in GNAT Pro. This feature was not implemented
> for our amusement, but rather in response to serious customer needs.
>
> Robert Dewar
> Ada Core Technologies

Re: 'withing' problem

[David Crocker]

It's our own library. As an example of the problem:

We define a base class 'anything' from which all other classes derive (like
Java's 'Object'). This base class has an abstract method 'toString' (just
like Java) having a return type 'seq of char' (where 'seq' is a templated
type representing a sequence). But 'seq' is, like all other classes, derived
from 'anything'. So the declaration of 'anything' needs to see a forward
declaration of 'seq'.

David Crocker, Escher Technologies Ltd. www.eschertech.com


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vitcsi70f.fsf@smaug.pushface.org...
> "David Crocker" <dcrocker@imsltd.com> writes:
>
> We have exactly this problem! (though I'm surprised at your difficulty
> compiling the runtime library? which library is that?)
>

Re: 'withing' problem

[tmoran]

>We define a base class 'anything' from which all other classes derive (like
>Java's 'Object'). This base class has an abstract method 'toString' (just
>like Java) having a return type 'seq of char' (where 'seq' is a templated
>type representing a sequence). But 'seq' is, like all other classes, derived
>from 'anything'.
  function toString(x : anything) return seq;
What does toString dispatch on, "anything", or "seq", or both?

Re: 'withing' problem

[Ted Dennison]

In article <3be65f4c$0$237$ed9e5944@reading.news.pipex.net>, David Crocker
says...
>
>OK, so if you think cross-dependency reflects bad design when the
>implementation language is Ada, can you tell me how you would redesign the
>Doctor/Patent/Insurer example in
>http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html ?

Make a new class called "symptom", which the doctor treats, and the patient has.
Make another new class called "insurer", which the doctor bills and the patient
has (and periodicly pays into). When a patient calls Visit_Doctor, they pass in
their symptom(s) and their insurer.

Circular dependancies are just as bad an idea in OO control flows as they are in
traditional logic control flows. Think about what used to result back when
people made their own loops using all sorts of interrelated goto's. When
designing you should be looking for hierarchy and structure, not just any old
path through your objects that seems to work.

I understand that in early OO, objects each had their own control (like
threads). If this were the case today we wouldn't even be having this
conversation. You are trying to make multiple objects both servers and clients
with each other, which is a perfect design for deadlock.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: 'withing' problem

[David Crocker]

Using the Ada-like notation of your example, 'toString' dispatches on the
type of parameter x. In fact, the call is written 'expr.toString' as in
other OO languages, so (unlike the case in Ada) it is obvious what the call
dispatches on.

Regards

David Crocker, Escher Technologies Ltd. www.eschertech.com


<tmoran@acm.org> wrote in message
news:fxAF7.23429$wj5.13409982@news1.rdc1.sfba.home.com...
> >We define a base class 'anything' from which all other classes derive
(like
> >Java's 'Object'). This base class has an abstract method 'toString' (just
> >like Java) having a return type 'seq of char' (where 'seq' is a templated
> >type representing a sequence). But 'seq' is, like all other classes,
derived
> >from 'anything'.
>   function toString(x : anything) return seq;
> What does toString dispatch on, "anything", or "seq", or both?

Re: 'withing' problem

[David Crocker]

Ted, I think you are saying that when a Patient object calls VisitDoctor, it
should pass all relevant information (e.g. symptom and insurer) as
parameters.

In a simple case this may work well, but consider that, depending on the
symptom and the particular doctor, the VisitDoctor procedure may require
various additional items of information; how old the patient is, whether he
smokes, whether he has a family history of particular diseases etc. These
are all semi-static attributes of the patient. We would end up with a huge
parameter list for VisitDoctor and much of the time, most of these
parameters would not be needed. Surely it is much simpler to have
VisitDoctor request these extra bits of information from the patent as and
when they are required? This certainly doesn't constitute a complex control
flow. Most OO developers would probably not even think of a call to a
side-effect-free member function of an object as control flow at all.

I agree that it is possible to use circular dependencies to create very
complex and hard-to-understand programs, but *any* powerful programming
feature can be used badly.

Regarding the OO model where every object has its own threads, I don't think
the model normally restricts each object to a single blocking thread, at
least in respect of methods that don't change the object's state. Or, to put
it another way, when an object sends a message to another object and is
waiting for a reply, it can still receive and process a message from a third
object before that reply is received, unless synchronisation mechanisms are
used to prevent this.

Regards

David Crocker, Escher Technologies Ltd. www.eschertech.com

"Ted Dennison" <dennison@telepath.com> wrote in message
news:ELCF7.13612$xS6.18271@www.newsranger.com...
> In article <3be65f4c$0$237$ed9e5944@reading.news.pipex.net>, David Crocker
> says...
> >
> >OK, so if you think cross-dependency reflects bad design when the
> >implementation language is Ada, can you tell me how you would redesign
the
> >Doctor/Patent/Insurer example in
> >http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html ?
>
> Make a new class called "symptom", which the doctor treats, and the
patient has.
> Make another new class called "insurer", which the doctor bills and the
patient
> has (and periodicly pays into). When a patient calls Visit_Doctor, they
pass in
> their symptom(s) and their insurer.
>
> Circular dependancies are just as bad an idea in OO control flows as they
are in
> traditional logic control flows. Think about what used to result back when
> people made their own loops using all sorts of interrelated goto's. When
> designing you should be looking for hierarchy and structure, not just any
old
> path through your objects that seems to work.

Re: 'withing' problem

[tmoran]

> Using the Ada-like notation of your example, 'toString' dispatches on the
> type of parameter x. In fact, the call is written 'expr.toString' as in
> other OO languages, so (unlike the case in Ada) it is obvious what the call
> dispatches on.
  Actually, it's not the case that
   function toString(x : anything) return seq;
shows an ambiguity about dispatching in Ada, since it's not (legal) Ada.

> We define a base class 'anything' from which all other classes derive (like
> Java's 'Object'). This base class has an abstract method 'toString' (just
> like Java) having a return type 'seq of char' (where 'seq' is a templated
> type representing a sequence). But 'seq' is, like all other classes, derived
> from 'anything'.
   Does "seq" have any children?  Does it inherit things from "anything"?
Given "x : seq;", what does "toString(x);" produce?  More generally,
why is "seq" derived from "anything" rather than just standing on its own?

> So the declaration of 'anything' needs to see a forward declaration of 'seq'.
Actually it's the declaration of "toString" that needs a preceding declaration
of "seq".

How about

  type anything is tagged null record;
  type seq is new anything with record
    ...
  end record;
  function toString(x:anything'class) return seq;

and then use overloading to create

  function toString(x : first_child_of_anything'class) return seq;
  function toString(x : second_child_of_anything'class) return seq;
  function toString(x : first_of_first_child_of_anything'class) return seq;
etc.
Then calls look like
  a_seq := first_child.toString(x);
  a_seq := second_child.toString(y);
  a_seq := first_of_first_child.toString(x);

Re: 'withing' problem

[David Crocker]

<tmoran@acm.org> wrote in message
news:io%F7.3554$Mt6.1856123@news1.rdc1.sfba.home.com...
>    Does "seq" have any children?  Does it inherit things from "anything"?
> Given "x : seq;", what does "toString(x);" produce?  More generally,
> why is "seq" derived from "anything" rather than just standing on its own?

It is usual in OO languages for all classes to derive from a base class. One
of the reasons is that it lets you write things like:

procedure print(x: anything'class, ...)

The implementation of 'print' would call 'toString(x)' and output the
result. So I can use 'print' to print any object I like, and provided the
declaration of the class concerned has overridden the 'toString' method, the
result will make sense (if the class didn't override 'toString', the default
implementation in 'anything' will yield "unprintable object" or something
like that).

> Actually it's the declaration of "toString" that needs a preceding
declaration of "seq".

Correct. But the declaration of 'toString' needs to be in the package for
'anything', so the package for 'anything' needs to 'with' the package for
'seq', and vice versa.

> How about
>
>   type anything is tagged null record;
>   type seq is new anything with record
>     ...
>   end record;
>   function toString(x:anything'class) return seq;
>
> and then use overloading to create
>
>   function toString(x : first_child_of_anything'class) return seq;
>   function toString(x : second_child_of_anything'class) return seq;
>   function toString(x : first_of_first_child_of_anything'class) return
seq;
> etc.

This looks viable, but it means that 'seq' and 'anything' must be declared
in the same package. Unfortunately, every cross-dependency results in the
classes concerned having to be placed in the same package, so before long
you end up with the whole program being in a single package. What we would
like is that each class in the original language becomes a separate package
in Ada.

Thanks for your input.

David Crocker, Escher Technologies Ltd. www.eschertech.com

Re: 'withing' problem

[Ted Dennison]

In article <3be80724$0$238$ed9e5944@reading.news.pipex.net>, David Crocker
says...
>In a simple case this may work well, but consider that, depending on the
>symptom and the particular doctor, the VisitDoctor procedure may require
>various additional items of information; how old the patient is, whether he
>smokes, whether he has a family history of particular diseases etc. These
>are all semi-static attributes of the patient. We would end up with a huge
>parameter list for VisitDoctor and much of the time, most of these

No. You can just put all that stuff in a "cookie" subrecord
(Medical_History_Form), which the patient has to fill out before the first
visit, and which may get updated by the doctor upon each visit.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: 'withing' problem

[Darren New]

Ted Dennison wrote:
> No. You can just put all that stuff in a "cookie" subrecord
> (Medical_History_Form), which the patient has to fill out before the first
> visit, and which may get updated by the doctor upon each visit.

How about "does it hurt when I do this?" kind of question? It seems like
what you're recommending is that the patent answer every possible
question that any Doctor (regardless of subclass) might ever ask, and
put them in a flat record to pass to the doctor. In other words, it
sounds like you're recommending that the OO aspects be eliminated in
this case.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
     Sore feet from standing in line at airport
                 security checkpoints: Jet Leg.

Re: 'withing' problem

[tmoran]

> The implementation of 'print' would call 'toString(x)' and output the result.
  I thought toString might be intended for that, but then I'd expect it to
return a fixed type like String, not some extendable (ie, variable) type "seq".

> Correct. But the declaration of 'toString' needs to be in the package for
> 'anything', so the package for 'anything' needs to 'with' the package for
> 'seq', and vice versa.
> >   function toString(x:anything'class) return seq;

  If toString takes "anything'class", then it's not a primitive of "anything"
and needn't be declared in the same package as "anything".  In particular,
"toString" and "seq" can be declared together in a package that with's
the package that declares "anything".

package Root_Of_All is
  type anything is tagged null record;
  ...
end Root_Of_All;

with Root_Of_All;
package Debugging_Help is
  type seq is new anything with record
    ...
  end record;
  function toString(x:Root_Of_All.anything'class) return seq;
  -- yields "unprintable object" as seq
  -- Should be overloaded for printable objects
  ...
end Debugging_Help;

with Root_Of_All, Debugging_Help;
package Something is
  type heir is new ... --- descendent of "anything"
  function toString(x:heir'class) return seq;
  -- seq is suitable for printing for debugging or whatever
  ...

Re: 'withing' problem

[Preben Randhol]

On 04 Nov 2001 10:23:48 +0000, Simon Wright wrote:
> Do you think that software designed with mutual dependency is less
> reliable? less safe? more expensive? If there's a compelling argument,

If it leads to increased complexity, yes!

> OK, otherwise I stand by "unfortunate limitation".

I guess one could use the argumentation to say that the lack of unsafe
pointers in Ada is also an "unfortunate limitation"?

Preben
-- 
Please, stop bombing civilians in Afghanistan. One cannot write off
killing innocent children and other civilians as "collateral damage".
A civilian is a civilian whether he or she is American or from another
country in the world.           http://web.amnesty.org/11september.htm

Re: 'withing' problem

[David Crocker]

<tmoran@acm.org> wrote in message
news:uwfG7.2665$Vf4.1461632@news1.rdc1.sfba.home.com...

>   I thought toString might be intended for that, but then I'd expect it to
> return a fixed type like String, not some extendable (ie, variable) type
"seq".

The language we are starting from defines 'string' to be a pseudonym for
'seq of char'. 'seq' is a template (i.e. generic) and final (i.e.
non-extendable) class.

>   If toString takes "anything'class", then it's not a primitive of
"anything"
> and needn't be declared in the same package as "anything".  In particular,
> "toString" and "seq" can be declared together in a package that with's
> the package that declares "anything".

Good point, I hadn't thought of that. Normally, 'toString' would need to be
declared in the same package as the type for which it is being defined (so
it can access the data), but since 'anything' contains no data, in this case
we could define it in package 'seq', or in its own package. This might give
us a route to compiling the runtime library, although we would still need to
prohibit mutual cross-referencing between classes in the original source
when we are generating Ada.

David Crocker, Escher Technologies Ltd. www.eschertech.com

Re: 'withing' problem

[Peter Hend�n]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

Preben Randhol wrote:
> I guess one could use the argumentation to say that the lack of unsafe
> pointers in Ada is also an "unfortunate limitation"?

But Ada _has_ unsafe pointers, hasn't it?

In my mind, the suggestions given for avoiding circular specification
dependencies are more cumbersome and unsafe than the
circularity itself. I would really like to see more detailed arguments
against allowing circular dependencies.

That said, I would agree that they should be avoided whenever
possible, in the same way that goto, unchecked_* and others
should be avoided.

/Peter H.
--
Peter Hend�n           http://www.algonet.se/~phenden
ICQ: 14672398
Teknisk Dokumentation AB          http://www.tdab.com

Re: 'withing' problem

[Matthew Heaney]

"David Crocker" <dcrocker@imsltd.com> wrote in message
news:3be65f4c$0$237$ed9e5944@reading.news.pipex.net...
> OK, so if you think cross-dependency reflects bad design when the
> implementation language is Ada, can you tell me how you would redesign the
> Doctor/Patent/Insurer example in
> http://home.bluemarble.net/~jvolan/WithingProblem/FAQ.html ?

There is no withing problem.  One possible solution appears below.

John is confused, and I recommend you disregard his paper.

Use gnatchop to extract the sources below.

--STX
with Patients; use Patients;

package body Doctors is

   procedure Treat_Patient
     (Doctor : in out Doctor_Type;
      Patient : in out Root_Patient'Class) is

      P : Patient_Type'Class renames Patient_Type'Class (Patient);
   begin
      null;
   end;


   procedure Bill_Patient
     (Doctor : in out Doctor_Type;
      Patient : in out Root_Patient'Class) is

      P : Patient_Type'Class renames Patient_Type'Class (Patient);
   begin
      Pay_Doctor (P, Doctor);
   end;


end Doctors;
with Patients_Forward; use Patients_Forward;

package Doctors is

   type Doctor_Type is tagged limited null record;

   procedure Treat_Patient
     (Doctor : in out Doctor_Type;
      Patient : in out Root_Patient'Class);

   procedure Bill_Patient
     (Doctor : in out Doctor_Type;
      Patient : in out Root_Patient'Class);

end;
   with Doctors; use Doctors;

package body Patients is

   procedure Visit_Doctor
     (Patient : in out Patient_Type;
      Doctor  : in out Doctor_Type) is
   begin
      Treat_Patient (Doctor, P);
   end;

   procedure Pay_Doctor
     (Patient : in out Patient_Type;
      Doctor  : in out Doctor_Type) is
   begin
      null;
   end;

end Patients;
with Patients_Forward; use Patients_Forward;
with Doctors; use Doctors;

package Patients is

   type Patient_Type is new Root_Patient with null record;

   procedure Visit_Doctor
     (Patient : in out Patient_Type;
      Doctor  : in out Doctor_Type);

   procedure Pay_Doctor
     (Patient : in out Patient_Type;
      Doctor  : in out Doctor_Type);

end;
package Patients_Forward is

   type Root_Patient is abstract tagged limited null record;

end;

Re: 'withing' problem

[Preben Randhol]

On Fri, 9 Nov 2001 15:28:48 -0500, Matthew Heaney wrote:
> package body Patients is
> 
>    procedure Visit_Doctor
>      (Patient : in out Patient_Type;
>       Doctor  : in out Doctor_Type) is
>    begin
>       Treat_Patient (Doctor, P);
                               ^
                               shouldn't it be Patient here?

                               gnatgcc -c patients.adb
                               patients.adb:9:30: "P" is undefined
                               gnatmake: "patients.adb" compilation error

>    end;
> 
>    procedure Pay_Doctor
>      (Patient : in out Patient_Type;
>       Doctor  : in out Doctor_Type) is
>    begin
>       null;
>    end;
> 
> end Patients;

Preben
-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: 'withing' problem

[Simon Wright]

Preben Randhol <randhol+abuse@pvv.org> writes:

> On 04 Nov 2001 10:23:48 +0000, Simon Wright wrote:
> > Do you think that software designed with mutual dependency is less
> > reliable? less safe? more expensive? If there's a compelling argument,
> 
> If it leads to increased complexity, yes!

Well, I would agree with you, but since the main reason for allowing
this (in the contexts I have in mind) is to _reduce_ complexity, at
any rate of the source code, I don't think it's an issue.

Re: 'withing' problem

[Simon Wright]

"David Crocker" <dcrocker@imsltd.com> writes:

> The language we are starting from defines 'string' to be a pseudonym
> for 'seq of char'. 'seq' is a template (i.e. generic) and final
> (i.e.  non-extendable) class.

It does seem that you are making life very difficult for yourself!
Must you retain this feature, it seems very problem-ridden for Ada. Of
course if it appears everywhere, not just with strings, that wouldn't
help.

I thought you were working in a model-based environment? Is this
"language we are starting from" an integral part of that environment,
or somewhat intermediate? If the latter, perhaps it could bend a bit?

Re: 'withing' problem

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> There is no withing problem.  One possible solution appears below.


> with Patients_Forward; use Patients_Forward;
> 
> package Doctors is


> with Patients_Forward; use Patients_Forward;
> with Doctors; use Doctors;
> 
> package Patients is


I think the thing I find most awkward is the asymmetry here. When you
look at a model (UML I mean, of course), how are you going to know
which way to jump?

Re: 'withing' problem

[Matthew Heaney]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrn9uqgc5.cu.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Fri, 9 Nov 2001 15:28:48 -0500, Matthew Heaney wrote:
> > package body Patients is
> >
> >    procedure Visit_Doctor
> >      (Patient : in out Patient_Type;
> >       Doctor  : in out Doctor_Type) is
> >    begin
> >       Treat_Patient (Doctor, P);
>                                ^
>                                shouldn't it be Patient here?
>
>                                gnatgcc -c patients.adb
>                                patients.adb:9:30: "P" is undefined
>                                gnatmake: "patients.adb" compilation error
>
> >    end;

Yes.  I should also have declared object Doctor as type Doctor_Type'Class
(so that Treat_Doctor dispatches).

Re: 'withing' problem

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vu1w2bil4.fsf@smaug.pushface.org...
> "Matthew Heaney" <mheaney@on2.com> writes:
> I think the thing I find most awkward is the asymmetry here.

If you have a cycle, you only have to break the cycle in one place.  I
arbitrarily picked the Patient type.


> When you
> look at a model (UML I mean, of course), how are you going to know
> which way to jump?

I don't understand your question.

Re: 'withing' problem

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vu1w2bil4.fsf@smaug.pushface.org...
> > "Matthew Heaney" <mheaney@on2.com> writes:
> > I think the thing I find most awkward is the asymmetry here.
>
> If you have a cycle, you only have to break the cycle in one place.  I
> arbitrarily picked the Patient type.
>
>
> > When you
> > look at a model (UML I mean, of course), how are you going to know
> > which way to jump?
>
> I don't understand your question.

I'm presuming that most of us start from some sort of visual model:

 +--------------------+                            +-------------------+
 |                    | 1                     0..n |                   |
 |      Doctor        |----------------------------|     Patient       |
 |                    |           treats           |                   |
 +--------------------+                            +-------------------+

I think that people looking at this model, perhaps for the purpose of
maintaining code written to implement it, need to have a very clear
idea of how the code will look.

It's a Bad Thing if you need to make arbitrary decisions to break
cycles.

What would be even worse would be to have a framework code generator
that applied heuristics to break cycles. I imagine that it wouldn't
take much for such heuristics to make the opposite decision for minor
model changes (remember that very few models are as simple as this
one!)

Re: 'withing' problem

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vy9lbxih0.fsf@smaug.pushface.org...
> I think that people looking at this model, perhaps for the purpose of
> maintaining code written to implement it, need to have a very clear
> idea of how the code will look.

My philosophy is, if you want to have a good idea how the code will look,
then you should look at the code...  In any case, you should just ignore the
forward declaration package, as it's just syntactic overhead that has no
bearing on your model of the problem.

> It's a Bad Thing if you need to make arbitrary decisions to break
> cycles.

You haven't explained why arbitrary decisions are bad, so this isn't a very
cogent argument, which just reduces to "I don't like it, so it's bad."

And besides, this solution is no different from other areas of the language.
For example, if you want to declare a recursive pair of subprograms, then
you have to forward declare one of them (and it's arbitrary which one):

declare
   procedure Op1;
   procedure Op2 is
   begin
      Op1;
   end;
   procedure Op1 is
   begin
      Op2;
   end;
begin
   null;
end;


> What would be even worse would be to have a framework code generator
> that applied heuristics to break cycles. I imagine that it wouldn't
> take much for such heuristics to make the opposite decision for minor
> model changes (remember that very few models are as simple as this
> one!)

Let's concentrate on real problems.  John Volan couldn't figure out how to
declare two mutually dependent abstractions in two separate packages.  I
showed how to do this.  Problem solved.

Re: 'withing' problem

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vy9lbxih0.fsf@smaug.pushface.org...
> > I think that people looking at this model, perhaps for the purpose of
> > maintaining code written to implement it, need to have a very clear
> > idea of how the code will look.
> 
> My philosophy is, if you want to have a good idea how the code will look,
> then you should look at the code...  In any case, you should just ignore the
> forward declaration package, as it's just syntactic overhead that has no
> bearing on your model of the problem.
> 
> > It's a Bad Thing if you need to make arbitrary decisions to break
> > cycles.
> 
> You haven't explained why arbitrary decisions are bad, so this isn't a very
> cogent argument, which just reduces to "I don't like it, so it's bad."

Well, "arbitrary" translates roughly to "unpredictable", "surprising"
both of which are definitely bad (I think so, anyway).

> And besides, this solution is no different from other areas of the language.
> For example, if you want to declare a recursive pair of subprograms, then
> you have to forward declare one of them (and it's arbitrary which one):

Here, you can "arbitrarily" (or following the warnings given by
-gnaty) forward declare _both_ (ie, _all_) subprograms. Symmetric.

> > What would be even worse would be to have a framework code generator
> > that applied heuristics to break cycles. I imagine that it wouldn't
> > take much for such heuristics to make the opposite decision for minor
> > model changes (remember that very few models are as simple as this
> > one!)
> 
> Let's concentrate on real problems.  John Volan couldn't figure out
> how to declare two mutually dependent abstractions in two separate
> packages.  I showed how to do this.  Problem solved.

This topic is a real problem for me.


Does your Patient_Forward solution extends to declaring Doctor_Forward
similarly? I get trouble at

   procedure Visit_Doctor
     (Patient : in out Patient_Type;
      Doctor  : in out Root_Doctor'Class) is
   begin
      Treat_Patient (Doctor, Patient);
patients.adb:9:22: expected type "Doctor_Type" defined at doctors.ads:6
patients.adb:9:22: found type "Root_Doctor'Class" defined at doctors_forward.ads:3
   end;

Re: 'withing' problem

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vu1vv6b02.fsf@smaug.pushface.org...
> Does your Patient_Forward solution extends to declaring Doctor_Forward
> similarly? I get trouble at
>
>    procedure Visit_Doctor
>      (Patient : in out Patient_Type;
>       Doctor  : in out Root_Doctor'Class) is
>    begin
>       Treat_Patient (Doctor, Patient);
> patients.adb:9:22: expected type "Doctor_Type" defined at doctors.ads:6
> patients.adb:9:22: found type "Root_Doctor'Class" defined at
doctors_forward.ads:3
>    end;

You have to make another renaming declaration, like you did in the Doctor
body:

procedure Visit_Doctor
  (Patient : in out Patient_Type;
   Doctor : in out Root_Doctor'Class) is

   D : Doctor_Type'Class renames Doctor_Type'Class (Doctor);
begin
   Treat_Patient (D, Patient);
end;

You got a compile error because Treat_Patient is not an operation of type
Root_Doctor.  To fix it, you have to downcast from type Root_Doctor'Class to
Doctor_Type'Class.

Re: 'withing' problem

[Stephen Leake]

I'm just voicing my support for Simon here. Forcing tools to break
withing cycles is a bad idea. The "with type" extension in GNAT is a
good way to solve the problem. 

Apparently there are some issues with it that make it not a good idea
in general; I hope that either a replacement is found soon, or that
the ARG decides that the benefits outweigh the problems.


Simon Wright <simon@pushface.org> writes:

> "Matthew Heaney" <mheaney@on2.com> writes:
> 
> > "Simon Wright" <simon@pushface.org> wrote in message
> > news:x7vy9lbxih0.fsf@smaug.pushface.org...
> > > I think that people looking at this model, perhaps for the purpose of
> > > maintaining code written to implement it, need to have a very clear
> > > idea of how the code will look.
> > 
> > My philosophy is, if you want to have a good idea how the code will look,
> > then you should look at the code...  In any case, you should just ignore the
> > forward declaration package, as it's just syntactic overhead that has no
> > bearing on your model of the problem.
> > 
> > > It's a Bad Thing if you need to make arbitrary decisions to break
> > > cycles.
> > 
> > You haven't explained why arbitrary decisions are bad, so this isn't a very
> > cogent argument, which just reduces to "I don't like it, so it's bad."
> 
> Well, "arbitrary" translates roughly to "unpredictable", "surprising"
> both of which are definitely bad (I think so, anyway).
> 
> > And besides, this solution is no different from other areas of the language.
> > For example, if you want to declare a recursive pair of subprograms, then
> > you have to forward declare one of them (and it's arbitrary which one):
> 
> Here, you can "arbitrarily" (or following the warnings given by
> -gnaty) forward declare _both_ (ie, _all_) subprograms. Symmetric.
> 
> > > What would be even worse would be to have a framework code generator
> > > that applied heuristics to break cycles. I imagine that it wouldn't
> > > take much for such heuristics to make the opposite decision for minor
> > > model changes (remember that very few models are as simple as this
> > > one!)
> > 
> > Let's concentrate on real problems.  John Volan couldn't figure out
> > how to declare two mutually dependent abstractions in two separate
> > packages.  I showed how to do this.  Problem solved.
> 
> This topic is a real problem for me.
> 
> 
> Does your Patient_Forward solution extends to declaring Doctor_Forward
> similarly? I get trouble at
> 
>    procedure Visit_Doctor
>      (Patient : in out Patient_Type;
>       Doctor  : in out Root_Doctor'Class) is
>    begin
>       Treat_Patient (Doctor, Patient);
> patients.adb:9:22: expected type "Doctor_Type" defined at doctors.ads:6
> patients.adb:9:22: found type "Root_Doctor'Class" defined at doctors_forward.ads:3
>    end;
> 

-- 
-- Stephe

Re: 'withing' problem

[Richard Riehle]

Simon Wright wrote:

> Well, "arbitrary" translates roughly to "unpredictable", "surprising"
> both of which are definitely bad (I think so, anyway).

Actually, all notation begins, at some point, on the basis of arbitrary
assumptions.   One may construct a system for further reasoning about
those assumptions, but even the foundation for that system is rooted
in arbitrary assumptions.

The UML association shown in an earlier posting illustrates one of the
traps in using UML notation in an incomplete way.   A class diagram
is a static representation of a model.   It is only one way of looking at
the whole model.   One can think of the class diagram as a family portrait
where we can identify the relationships between the members of the
family, but cannot see the dynamics of those relationships.

A more complete model will include the dynamics of those relationships.
As soon as we begin to see the sequence diagrams, activity diagrams, and
collaboration diagrams, we also can determine where we must adjust our
static model.   Grady uses the term, "round-trip gestalt process," to emphasize
the need to continually refine our model based on what we discover in other
views of the model.

As much as it pains me to agree with Matthew Heaney [ :-) ] ,  I have to
do so here.   The circular dependency in the Patient/Doctor design is a
contrivance that fails to reflect A correct design of a medical system. It
is reminiscent of the question, "Can God build a wall so high he cannot
climb over it?"   In the mathematical sense, it is reminiscent of Zeno's
paradox.

Richard Riehle

Re: 'withing' problem

[Simon Wright]

Richard Riehle <richard@adaworks.com> writes:

> As much as it pains me to agree with Matthew Heaney [ :-) ] , I have
> to do so here.  The circular dependency in the Patient/Doctor design
> is a contrivance that fails to reflect A correct design of a medical
> system. It is reminiscent of the question, "Can God build a wall so
> high he cannot climb over it?"  In the mathematical sense, it is
> reminiscent of Zeno's paradox.

He that would have eggs must endure the cackling of hens.


If there is a real-world circularity between doctor and patient, and
our software engineering tools can't cope with it, it's the tools that
have failed and not the real world!

Re: 'withing' problem

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Richard Riehle <richard@adaworks.com> writes:
> 
> > As much as it pains me to agree with Matthew Heaney [ :-) ] , I have
> > to do so here.  The circular dependency in the Patient/Doctor design
> > is a contrivance that fails to reflect A correct design of a medical
> > system. It is reminiscent of the question, "Can God build a wall so
> > high he cannot climb over it?"  In the mathematical sense, it is
> > reminiscent of Zeno's paradox.
> 
> He that would have eggs must endure the cackling of hens.

I'm very sorry. I was trying to show that two could play at using
gnomic proverbs, and instead I end up insulting Richard. This was
*not* my intention. Richard has valid points which I happen to
disagree with.

Re: 'withing' problem

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vd72gi0zm.fsf@smaug.pushface.org...
> If there is a real-world circularity between doctor and patient, and
> our software engineering tools can't cope with it, it's the tools that
> have failed and not the real world!

This reminds me of something I read on Robert Pirsig's Zen and the Art of
Motorcycle Maintenance.  When the platypus was discovered (it's a mammal
that lays eggs), scientists concluded that it was a freak of nature!
Pirsig/Phaedrus argued that that was a ridiculous reaction.  Nature does
whatever works, however odd humans may find that.  That some animal doesn't
neatly fit into a the taxonomy crafted by human observers is irrelevant.

The issue here is that none of us agree what "failure" means.  I am
satisfied that the Doctor/Patient relationship can be modeled adequately.
Yes, there is some syntactic baggage that is required, and there's an extra
Tag_Check I'm not crazy about, but for me this gets the job done.  John
Volan argued that no solution was possible at all without a language change,
and I argued that his argument was flawed (by providing a counterexample).

Simon argued that my solution was inadequate, because there was no simple
way to a automatically generate my code from the UML diagram.

Who's right?  The answer of course depends on the observer.

Re: 'withing' problem [code generation]

[Mark Johnson]

Matthew Heaney wrote:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vd72gi0zm.fsf@smaug.pushface.org...
> > If there is a real-world circularity between doctor and patient, and
> > our software engineering tools can't cope with it, it's the tools that
> > have failed and not the real world!
> [snip]
> Simon argued that my solution was inadequate, because there was no simple
> way to a automatically generate my code from the UML diagram.

Having done code generation from diagrams before - I guess I don't understand
why there is no "simple way to automatically generate code" in this case. I see
at least two "simple solutions" that are not mutually exclusive:
 - annotate the drawing to "break the circular dependency here"
 - recognize patterns of circular dependencies and generate code that
automatically generates the new packages (and report such changes to the user)

We were taking data flow and control flow diagrams to generate the code for an
aircraft simulator. Loops appeared all over the place as systems interact with
each other. However, we had to "pick one" to run first (on a single CPU). The
code generator sorted the blocks based on how "close" the block was to an
external input. Direct connections were "1", blocks connected to "1's" were "2",
and so on. The precise order the blocks executed was deferred to run time - we
ran all blocks directly connected to inputs that *changed* first, then all
blocks connected to first level outputs, and so on using the order described
above. That tended to minimize latency in our system - which we considered a
*good thing*.

In a similar manner, you would probably want to do both simple solutions and use
the user directed solution in preference to an automatic one [that may be less
optimal for some reason]. This is because you will do all this in a static
manner - unlike the simulator example.

The "how to annotate" the drawing is left as an exercise to the developer of the
code generator. In our system, there was some control data that we imported
separately from the drawings & data dictionary. Mostly a big table that we
entered in Excel and exported to columns in a tab separated text file.
  --Mark

Re: 'withing' problem

[Preben Randhol]

On Mon, 19 Nov 2001 10:23:53 -0500, Matthew Heaney wrote:
> This reminds me of something I read on Robert Pirsig's Zen and the Art of
> Motorcycle Maintenance.  When the platypus was discovered (it's a mammal
> that lays eggs), scientists concluded that it was a freak of nature!

[...]

> Simon argued that my solution was inadequate, because there was no simple
> way to a automatically generate my code from the UML diagram.

Conclusion; the solution is a freak of UML. ;-) Seriously, as a chemist
I would wish that it would be easier to model the nature, but the
problem is that the nature is extremely complex. One have to make
solutions that have some sort of assumptions in them that can be
justified.

Preben Randhol
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: 'withing' problem [code generation]

[Stephen Leake]

Mark Johnson <Mark_H_Johnson@Raytheon.com> writes:

> Matthew Heaney wrote:
> 
> > "Simon Wright" <simon@pushface.org> wrote in message
> > news:x7vd72gi0zm.fsf@smaug.pushface.org...
> > > If there is a real-world circularity between doctor and patient, and
> > > our software engineering tools can't cope with it, it's the tools that
> > > have failed and not the real world!
> > [snip]
> > Simon argued that my solution was inadequate, because there was no simple
> > way to a automatically generate my code from the UML diagram.
> 
> Having done code generation from diagrams before - I guess I don't understand
> why there is no "simple way to automatically generate code" in this case. I see
> at least two "simple solutions" that are not mutually exclusive:
>  - annotate the drawing to "break the circular dependency here"

This is not "automatic", it's "manual". That's the point.

>  - recognize patterns of circular dependencies and generate code
> that automatically generates the new packages (and report such
> changes to the user)

This may be possible. The problem is that the automatic recogition of
patterns may be unstable; small changes in the UML model may make
large changes in the new packages. 

For example, assume your UML model has the Doctor -> Patient
circularity. The first time you generate code, it may decide to break
the circularity by using a forward declaration for Doctor. Now you
tweak the model a bit, and it decides to forward declare Patient. Not
a Good Thing!

The point here is that extending Ada with "with type" allows some
"circularities" to be directly represented, without any user or tool
interaction.

> We were taking data flow and control flow diagrams to generate the
> code for an aircraft simulator. Loops appeared all over the place as
> systems interact with each other. However, we had to "pick one" to
> run first (on a single CPU). The code generator sorted the blocks
> based on how "close" the block was to an external input. Direct
> connections were "1", blocks connected to "1's" were "2", and so on.
> The precise order the blocks executed was deferred to run time - we
> ran all blocks directly connected to inputs that *changed* first,
> then all blocks connected to first level outputs, and so on using
> the order described above. That tended to minimize latency in our
> system - which we considered a *good thing*.

This sounds like it could be a stable algorithm, as long as there are
not parallel paths from the first block to the nth block.

-- 
-- Stephe

Re: 'withing' problem [code generation]

[Matthew Heaney]

"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u3d3aeavn.fsf@gsfc.nasa.gov...
> The point here is that extending Ada with "with type" allows some
> "circularities" to be directly represented, without any user or tool
> interaction.

The circularity can already be directly represented, by simply
forward-declaring one of the types.  A language change is only necessary in
order to change the syntax of the forward declaration, and to remove the
(small) run-time penalty.

(I should also add, "in order to interface to IDL and Java." But in the
latter case, still more language changes would be required, e.g. interface
types.)

>For example, assume your UML model has the Doctor -> Patient
>circularity. The first time you generate code, it may decide to break
>the circularity by using a forward declaration for Doctor. Now you
>tweak the model a bit, and it decides to forward declare Patient. Not
>a Good Thing!

I don't understand this argument.  If you're using a code generator, then
what difference does it make what code is generated?  If you care that much,
then why don't you just write the code manually?

Re: 'withing' problem [code generation]

[Mark Biggar]

Stephen Leake wrote:
> 
> Mark Johnson <Mark_H_Johnson@Raytheon.com> writes:
> > at least two "simple solutions" that are not mutually exclusive:
> >  - annotate the drawing to "break the circular dependency here"
> 
> This is not "automatic", it's "manual". That's the point.
> 
> >  - recognize patterns of circular dependencies and generate code
> > that automatically generates the new packages (and report such
> > changes to the user)
> 
> This may be possible. The problem is that the automatic recogition of
> patterns may be unstable; small changes in the UML model may make
> large changes in the new packages.

How about a hybrid approach,  Automatically break the cycle and then
automatically annotate the diagram so that it does it the same way
in the future.  Of course, if the user want to do the annotation
manually (like if he doesn't like the way the automatic system
did it) they he can.

Then there is the over specification approach, forward declare all
the types in the cycle in a symmetric way.

--
Mark Biggar
mark.a.biggar@home.com

Re: 'withing' problem [code generation]

[Mark Johnson]

Stephen Leake wrote:

> Mark Johnson <Mark_H_Johnson@Raytheon.com> writes:
>
> > Matthew Heaney wrote:
> > [snip]
>
> >  - annotate the drawing to "break the circular dependency here"
>
> This is not "automatic", it's "manual". That's the point.
>
> >  - recognize patterns of circular dependencies and generate code
> > that automatically generates the new packages (and report such
> > changes to the user)
>
> This may be possible. The problem is that the automatic recogition of
> patterns may be unstable; small changes in the UML model may make
> large changes in the new packages.
>

Exactly the reason I mentioned both solutions. If you *really care* about the
structure of the packages, allow the author to specify that certain rules to be
applied. The annotation I mentioned becomes a part of the standard you apply when
using UML. I don't see why you consider that "manual" - the computer does everything
based on your (now more complete) specification of the solution.

I thought about this a little last night and you have the circular dependency problem
in C if you are not careful. You get an infinite loop in the C preprocessor if
doctor.h includes patient.h and vice versa. Almost everybody codes their header files
to have some #ifundef that encloses the body of the header file. That way, each
header is expanded only once. Even with that, you could have a subtle bug due to the
different order of expansion - doctor before patient or patient before doctor. Icky,
nasty problems to find and fix..


> [snip - description of execution order algorithm]

> > That tended to minimize latency in our
> > system - which we considered a *good thing*.
>
> This sounds like it could be a stable algorithm, as long as there are
> not parallel paths from the first block to the nth block.

Of course there were parallel paths. All the cautions you mentioned about small
changes on the drawing making big changes in the way the code executed were true. Add
a single line on a drawing and a block that was executing 4 steps later is now
executing two steps previous. Even more - based on which inputs came in, the blocks
executed in a different order.

So what. We kept focused on the problem we were trying to solve and did not care so
much on how beautiful or ugly the generated code was. A common problem in simulators
is instability in the model due to excessive latency - our system never had that
problem because the solution minimized latency in all cases.

  --Mark

Re: 'withing' problem [code generation]

[David Crocker]

It's not hard to come up with a system that makes the order of C++ include
files unimportant. Our product currently generates C++ (we would like to
generate Ada, which is why I started this thread) so we needed just such a
scheme.

Our solution uses 2 header files for each main file. The phase 1 header file
just contains forward declarations for all the classes declared, then the
phase 2 header file contains the class declarations proper. Each main file
first includes all relevant phase 1 header files (in alphabetical order) and
then all relevant phase 2 header files (also in alphabetical order). The
phase 2 header files include other phase 2 header files only where there is
a strong dependency (i.e. class inheritance). Strong dependencies are not
circular. Of course, we also use the usual header guards to ensure each file
only gets included once.

The nicest solution is the one used by Java (and by our own product) - no
restriction at all on forward referencing classes/types, or on packages
referring to each other (except for absurd cases like 2 classes inheriting
from each other). This is the way all programming languages should go, IMO.
Forward-declarations should be considered obsolete - they only exist to make
life easier for the compiler writer, and compiler technology has come a long
way now.
--
David Crocker, Escher Technologies Ltd. www.eschertech.com


"Mark Johnson" <Mark_H_Johnson@Raytheon.com> wrote in message
news:3BFA6BDC.26E7557E@Raytheon.com...

(snip)

> I thought about this a little last night and you have the circular
dependency problem
> in C if you are not careful. You get an infinite loop in the C
preprocessor if
> doctor.h includes patient.h and vice versa. Almost everybody codes their
header files
> to have some #ifundef that encloses the body of the header file. That way,
each
> header is expanded only once. Even with that, you could have a subtle bug
due to the
> different order of expansion - doctor before patient or patient before
doctor. Icky,
> nasty problems to find and fix..

Re: 'withing' problem [code generation]

[Richard Pinkall-Pollei]

>Forward-declarations should be considered obsolete - they only exist
>to make life easier for the compiler writer ...

Hm.  I like forward declarations in that they point out circular
dependencies in a concrete way.  Thus, if I don't forward declare, I
get a compile error that tells me I may have an unintentional
dependancy.

-- 
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net

Re: 'withing' problem [code generation]

[Matthew Heaney]

"David Crocker" <dcrocker@imsltd.com> wrote in message
news:3bfa84ca$0$8514$ed9e5944@reading.news.pipex.net...
> It's not hard to come up with a system that makes the order of C++ include
> files unimportant. Our product currently generates C++ (we would like to
> generate Ada, which is why I started this thread) so we needed just such a
> scheme.

You have to forward declare the types in C++ too:

//chicken.hpp
class Egg;
class Chicken
{
public:
   void lay(Egg&);
};

//egg.hpp
class Chicken;
class Egg
{
public:
   void layer(Chicken*&) const;
};


> The nicest solution is the one used by Java (and by our own product) - no
> restriction at all on forward referencing classes/types, or on packages
> referring to each other (except for absurd cases like 2 classes inheriting
> from each other). This is the way all programming languages should go,
IMO.

That's swell.  Why don't you post this on comp.lang.c++ and see what the
reaction is.  My hunch is that most C++ programmers won't be sympathetic.

You cannot compare static languages like Ada95 and C++ to dynamic languages
like Java or Eiffel.  They were designed to solve different problems, and
hence reflect different philosophies.

> Forward-declarations should be considered obsolete - they only exist to
make
> life easier for the compiler writer, and compiler technology has come a
long
> way now.

It's called "type-checking."  The rule is that an entity has to be declared
before being used.  This is a deliberate feature of the language, and it's
there because the language designer wanted it to be there.  It has nothing
to do with compiler technology (since you could have easily designed the
language without that feature).

Re: 'withing' problem [code generation]

[Mark Lundquist]

"David Crocker" <dcrocker@imsltd.com> wrote in message
news:3bfa84ca$0$8514$ed9e5944@reading.news.pipex.net...
>
> The nicest solution is the one used by Java (and by our own product) - no
> restriction at all on forward referencing classes/types, or on packages
> referring to each other (except for absurd cases like 2 classes inheriting
> from each other). This is the way all programming languages should go,
IMO.

OK -- but isn't Java's solution more of just a side-benefit of being a
by-reference language?

It seems like there are some underlying trade-offs :-)

Cheers,
-- Mark Lundquist
http://members.home.com/mlundquist2/consulting

Re: 'withing' problem [code generation]

[Mark Lundquist]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tvl95d3asnbcd4@corp.supernews.com...
>
> It's called "type-checking."  The rule is that an entity has to be
declared
> before being used.  This is a deliberate feature of the language, and it's
> there because the language designer wanted it to be there.  It has nothing
> to do with compiler technology (since you could have easily designed the
> language without that feature).

Right!  It's not for the compiler writer's benefit.  It's for the
programmer's benefit.
-- mark

Re: 'withing' problem [code generation]

[Simon Wright]

"Matthew Heaney" <mheaney@on2.com> writes:

> I don't understand this argument.  If you're using a code generator,
> then what difference does it make what code is generated?  If you
> care that much, then why don't you just write the code manually?

If you were using a complete code generator (from executable UML, in
some way, for example) this is true. But in that case Ada would be a
kind of low-level language the developers wouldn't normally look at.

If the CG is producing a framework that the developers have to slot
code into, it matters a lot that the code they've written and tested
isn't invalidated by some minor model change.

Re: 'withing' problem [code generation]

[Simon Wright]

Mark Biggar <mark.a.biggar@home.com> writes:

> Then there is the over specification approach, forward declare all
> the types in the cycle in a symmetric way.

This is the way I would go.

Re: 'withing' problem [code generation]

[David Crocker]

No, Java's solution has nothing to do with the fact that Java non-primitive
types are reference types. It has everything to do with the compiler being
flexible enough process declarations in whatever order necessary to perform
type checking without needing forward declarations.

Our own language (see www.eschertech.com) does not treat non-primitive types
as reference types, and we also allow forward-referencing of and circular
depedencies between types. It does mean that you need at least a 2-pass
compiler, but the days when this meant physically reading the source twice
are long gone.
--
David Crocker, Escher Technologies Ltd. www.eschertech.com


"Mark Lundquist" <up.yerz@nospam.com> wrote in message
news:B8zK7.51483$XJ4.30270717@news1.sttln1.wa.home.com...
>
> "David Crocker" <dcrocker@imsltd.com> wrote in message
> news:3bfa84ca$0$8514$ed9e5944@reading.news.pipex.net...
> >
> > The nicest solution is the one used by Java (and by our own product) -
no
> > restriction at all on forward referencing classes/types, or on packages
> > referring to each other (except for absurd cases like 2 classes
inheriting
> > from each other). This is the way all programming languages should go,
> IMO.
>
> OK -- but isn't Java's solution more of just a side-benefit of being a
> by-reference language?
>
> It seems like there are some underlying trade-offs :-)
>
> Cheers,
> -- Mark Lundquist
> http://members.home.com/mlundquist2/consulting
>
>
>

Re: 'withing' problem [code generation]

[David Crocker]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tvl95d3asnbcd4@corp.supernews.com...

<snip>

> You cannot compare static languages like Ada95 and C++ to dynamic
languages
> like Java or Eiffel.  They were designed to solve different problems, and
> hence reflect different philosophies.

Sorry, you are making a big mistake if you believe that Eiffel and Java are
dynamic languages. Maybe you are thinking of Smalltalk. Eiffel and Java are
just as amenable to static type checking as C++ and Ada 95. The only feature
of Java that might be considered dynamic (and the results not statically
checkable) is the facility to load at run time new class files that didn't
exist when the program was compiled (or even when the program was loaded).