Re: Self-referential types

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Mon, 18 Oct 1999, Robert Dewar wrote:
> In article <38077EB3.E6911567@mitre.org>,
>   "Robert I. Eachus" <eachus@mitre.org> 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.
> 
>