From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 17 Jun 93 11:41:18 GMT From: 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) Subject: Re: Type declarations in a subprogram Message-ID: <1993Jun17.131003@lglsun.epfl.ch> List-Id: In article <1vnss6$dmv@usafa2.usafa.af.mil>, cwarack@kirk.usafa.af.mil (Chris W arack ) 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