From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e94a7e4f6f888766 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Self-referential types Date: 1999/10/18 Message-ID: #1/1 X-Deja-AN: 537762795 References: <7ttb4a$8mq$1@nnrp1.deja.com> <3802f2db_2@news1.prserv.net> <3803B5E3.F96A6DD4@mitre.org> <3803c8bc_2@news1.prserv.net> <3804E7E0.6A0265FB@mitre.org> <38077EB3.E6911567@mitre.org> <7udsq9$lv7$1@nnrp1.deja.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 940300381 204 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-10-18T00:00:00+00:00 List-Id: On Mon, 18 Oct 1999, Robert Dewar wrote: > In article <38077EB3.E6911567@mitre.org>, > "Robert I. Eachus" wrote: > > AFIAK, it is almost always poor engineering to declare > procedures > > within other procedures in Ada. The chief exception is > recursive descent > > parsers. > > What an *amazing* statement. I am completely flabbergasted! > > First, I don't see recursive descent parsers as being > relevant here, and see no reason for nesting there. The argument I hear is that by nesting the inner parsing routines have no arguments, FWIW. Also, when writing backtracking recursive descent parsers (OK, I've only done it once in Ada :-) the solution with procedure nesting and procedure parameters (faked with generics in Ada) seems fairly understandable to me. > There are however MANY MANY examples where nesting makes > excellent sense, and IMO any language that does not permit > nested procedures is badly broken, I agree, but IMO the readability argument, perhaps subsuming your arguments, is important enough that all other considerations are secondary. I find this true even in "sequential" Ada. -- Brian > > There are zillions of reasons for nesting, but let me just > give two. > > 1. Localization of names. If you have a small procedure that > is just called a couple of times within a single procedure, > it is FAR better to restrict its name space by nesting it > within the calling procedure, and it is indeed very bad > style to unnest it in this case. One particular case is > where you have a recursive implementation of a non recursive > procedure interface for the client, often referencing one > of the parameters of the outer procedure non-locally. > > 2. Nested procedures makes it FAR easier to make things thread > safe, because you can have variables that are "global" to a set > of cooperating procedures, but are still on a local > thread-specific stack of the enclosing procedurers. > In a language without nested procedures, you often see real > global variables used for this purpose, which is a common > source of non-thread safeness. Yes, you can take the position > that you should never have any non-local references, but this > often obfuscates the code and is error prone. > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > >