Re: Ammo-zilla

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

On Thu, 28 Oct 1999, Tucker Taft wrote:
> Charles Hixson wrote:
> > 
> > I am continually attracted to Ada, however:
> > The Ada approach to memory management reminds me of the PL/1 approach,
> > only simplified a bit.  I suppose that you can say that it's better than
> > C++, but that's *REALLY* faint praise.  There are a lot of details that
> > I don't fully understand, but this is one of Ada's weaker aspects.  The
> > second is the syntax used in "object" declaration.  Very clumsy.
> > 
> > Now I *do* understand that the reason for this approach is (partially
> > the date of design but also) to allow statically linked programs to be
> > small enough for embedded systems, etc.  And it is indeed necessary to
> > enable this.  But the cost of a unified design of this nature is that,
> > e.g., garbage collection is eliminated from the language.  (The syntax
> > is mainly due to early design.)  I feel relativly certain that if the
> > language were to be designed today that many things would have been done
> > differently.
> 
> That's an interesting question.  I have on occasion since we finalized
> the Ada 95 design thought about how I might design a language if I
> could really start from scratch.  After a huge amount of horsing around,
> I end up surprisingly close to where Ada 95 is now.  For example,
> you mention the "clumsy" syntax associated with object declarations.
> It is interesting to note that Haskell, one of the more elegant
> functional programming languages out there, has essentially the
> identical object approach as Ada 95, as does CLOS, common lisp object 
> system. 

Haskell doesn't support OOP, in particular, it doesn't support dynamic 
dispatch so I don't think the comaprison is appropriate. Besides Lisp 
derivatives like CLOS and Dylan, the only functional programming language 
I know of which supports OOP is Objective Caml. OCaml uses the
distinguished receiver notation with "#" instead of ".".

I prefer the Ada notation, but I don't think the notational choice is as 
big a deal as some people make it out to be. I think if you could design
Ada from scratch you could use some more tokens like "[", "]", "{", and 
"}" instead of using parens for everything.

> If you are used to the notion of an abstract data type, defined by a
> type and a set of operations, and then you decide you want to support
> extensibility of abstract data types, then you end up at something
> very much like Ada 95, Haskell, or CLOS, with the 
> "operation(operand, operand, ...)" or "operand <operator> operand"
> or "object := operation(operand, operand,...)" syntax familiar from
> theoretical mathematics and logic.  If you instead focus on
> updating objects as the primary operations of interest, then you end up with
> the <obj>.<operation> syntax.  In some ways, the Ada 95 syntax is
> more sympathetic with the "value-oriented" (i.e. functional) way
> of thinking than the "object-oriented" (i.e. side-effecting) way
> of thinking.  The net effect, in any case, is that you can more easily
> write in a "functional" style in Ada 95 where there is less use of
> heap-resident read/write objects, and more use of values (rather than 
> objects) of an abstract type being passed around, assigned, declared, etc. 

Agreed. Since there is this contingent of functional programming devotees
in the Ada community, perhaps we'll see anonymous access to subprogram 
types, downward closures via access to subprogram, and other FP tools in 
the next version of Ada :-). 

-- Brian