Re: Type declarations in a subprogram

[pipex!warwick!zaphod.crihan.fr!vishnu.jussieu.fr!univ-lyon1.fr!scsing.swi tch.ch!epflnews!disuns2.epfl.ch!lglsun!nebbe@uunet.uu.net (Robb Nebbe)]

In article <1vnss6$dmv@usafa2.usafa.af.mil>, cwarack@kirk.usafa.af.mil (Chris W
arack <sys mgr>) writes:
: In article <1993Jun16.164301@lglsun.epfl.ch> nebbe@lglsun.epfl.ch 
: (Robb Nebbe) writes:
: 
: > Why would anyone want to declare a type in a subprogram?
: 
: ... I have to ask why you wouldn't want it?  To prohibit it would just
: add additional rules that apply to some declarative parts but not to
: others.  Why is this a benefit?  It's simpler to define declarative
: parts the same.  Given that, you could declare a type in the middle of
: a loop if you wanted to by using a block statement.  I'll probably
: never do it, but it's nice to know that the declarative part of a
: package spec, subprogram, and block statement are the same.
: 
: -- 
: Christopher A. Warack, Capt, USAF
: Computer Science Department, US Air Force Academy
: 
: cwarack@kirk.usafa.af.mil                (719) 472-2401

I was particularly interested in type declarations in procedures
because of some of the restrictions that Ada 9X is placing on tagged
types and access to subprogram types.

If I'm not mistaken tagged types may not be declared or derived in the
declarative part of a subprogram. As Tucker is fond of saying this is
an engineering decision where the benefits were weighed against the
cost (in terms of implementation difficulty) and a decision made.

As you might guess (or know) having one uniform declarative part is
nice since it makes the language more regular but it doesn't come for
free. If you add the concept of class to a language then declaring a
class or subclass in a subprogram is theoretically complex and I will
trust the 9X teams decision that it is also complex to implement.

In Ada 83 declaring a subprogram inside another subprogram  introduces
the possibility of variable aliasing (this is declared erroneous in the
LRM but that doesn't make it go away) and can lead to problems when an
local procedure is used to instantiate a generic subprogram as seen by
the inability of numerous compilers to handle this correctly.

C just avoids the problem (and any benefits) entirely by not permitting
the programmer to declare a type or functions inside a function.

In computer science people tend to fall into the trap of always asking
why not rather than why. Proving that something is not bad is entirely
different than proving that it is good.

One of the traps that many begining C programmers fall into is assuming
that anything the compiler lets them do (and which is thus not bad) is
good.

It is probably worth noting that Wirth removed the ability to declare a
module in another module when he moved from Modula 2 to Oberon. His
justification was that while submodules were not bad they weren't good
either; so he took them out.

Well, I've gone on long enough.

Robb