Re: Looking for Ada Technique Name and References

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

On Tue, 29 Feb 2000, Jon S Anthony wrote:

> Brian Rogoff wrote:
> > 
> > Well, the topic has really changed, but if you are going to rank languages
> > based on their support for the functional programming paradigm, I'd give
> > Ada a fairly significant edge over C and C++ since
> 
> Agreed.
> 
> > (1) Ada is lexically scoped
> 
> ??? Surely you don't mean to imply that C/C++ are dynamically scoped?

No, C is lexically scoped too, but in a very trivial way, since you can't 
nest subprogram definitions. For those who aren't familiar with the
terminology, I mean that free variables in a block get their values from
the closest *textually* enclosing block, as opposed to getting its value 
from the runtime context like Emacs Lisp for example. 

Thanks for the prompt; what I wrote could easily mislead someone. Perhaps 
more precise terminology is called for. Or perhaps not, maybe I should
just have used a strong "and", the combination of lexical scope AND
subprogram nesting is what enables a limited FP style in Ada...

> > (2) Ada allows the use of nested subprograms as subprogram parameters to
> >     generic instantiations, allowing the crude simulation of downward
> >     funargs.
> 
> Agreed, but this is very crude indeed.

Yes, that's why I think it should be fixed. Generics are a heavyweight
mechanism for this, and there are a few cases (I posted one a long time 
ago based on some code Richard O'Keefe posted here) where using generics
is far less readable and reusable than something like Unrestricted_Access.

> > In my experience, this captures some small amount of FP style directly
> > which is awful in C and unpleasant in C++ (where you can overload "()"
> > and explicitly pass local state rather than directly referencing variables
> > from an enclosing scope).
> 
> I'm still not clear on why you think this means that C/C++ are not
> lexically
> scoped (or perhaps "less lexically scoped" than Ada).  Certainly passing
> local state around does not impact this.  I agree that there are cases
> where
> you _have_ to do this when a lexically scoped access is what you really
> want.

Because in Ada I can declare a subprogram nested in another, which refers
to local variables in the enclosing subprogram, and then use the nested 
subprogram as a parameter to a generic instantiation. I can't do that in 
C or C++, and to achieve the same effect I have to manually "lambda lift", 
and explicitly pass those local vars I'm interested in as method
arguments.

So, while they are strictly speaking lexically scoped, it isn't very
useful from a "coding FP" perspective. I hope that's clearer.

> 
> >Re: On Tue, 29 Feb 2000, Charles Hixson wrote:
> >> Even the various dialects of Lisp range from the purely functional (i.e.,
> >> where all constructs can be phrased as a functional call with sugar around
> >> it) to Common Lisp.  And none of these are what I now think of as the
> >> functional languages:  ML, OCaML, etc.
> >
> > I don't want to start a FP language war in c.l.ada, but why do you
> > consider "Pure Lisp", ML and OCaml functional, Common Lisp not? I use
> > references, arrays, and exceptions in my OCaml code...
> 
> Good question; direct support for iteration?  

Here's some legal OCaml from the manual

#let insertion_sort a =
   for i = 1 to Array.length a - 1 do
     let val_i = a.(i) in
     let j = ref i in
     while !j > 0 && val_i < a.(!j - 1) do
       a.(!j) <- a.(!j - 1);
       j := !j - 1
     done;
     a.(!j) <- val_i
   done;;

val insertion_sort : 'a array -> unit = <fun>

I guess OCaml isn't an FP then. Charles?

-- Brian