Re: Looking for Ada Technique Name and References

[Jon S Anthony <jsa@synquiry.com>]

> Brian Rogoff wrote:
>
> On Tue, 29 Feb 2000, Jon S Anthony wrote:
> > Brian Rogoff wrote:
> > > I guess OCaml isn't an FP then. Charles?
> > 
> > Well, he already claimed it was, so there must be some other
> > feature(s) of direct Lisp family members that excludes them in his
> > taxonomy.  I see OCaml also has assignment.
> 
> Yes. OCaml and SML both have references, mutable arrays, and
> exceptions, which mean they are not "pure" FPs like Haskell and
> Clean, and much closer to languages like Scheme.

Sound closer to CL/CLOS to me (a lot of machinery "out-of-the-box").


> My view (grunt programmer in the trenches) is that we judge a
> language by its support for a particular style, and don't worry
> about pure/impure distinctions.

Here we are in great alignment.  I would go even further and say that
single paradigm languages (so called "pure" OO or FP or ...) are
always at a significant disadvantage in being able to cleanly express
solutions to problems.  Problems are nearly always multi-faceted and
larger ones are typically mult-perspective.  To cleanly tackle these
things you really need cleanly and flexibly handle diverse
representations and processing paradigms.


> Lisp (ANSI CL), Scheme and the MLs all support FP style *much*
> better than those languages without first class functions. To me,
> first class functions are the sine-qua-non of FP, so these are all
> FPLs.

Again, we are in close agreement.  Certainly first class functions are
_necessary_.  At the end of the day, I would say that the exclusion of
assignment yields "pure" FPLs.  Assignment is an ugly nasty thing, but
it's advantages always seem to out weigh this.


> Some might argue that Haskell and Clean do best of all because they
> are lazy (a little lie; really "non-strict") by default.

I think there are many who would argue this, where "best" means
"purest" not actually "overall goodness" (at least IMO).


> I don't have enough practical experience here, when I tried to use
> Haskell in anger I found it way too slow.

I too do not have enough real experience with Haskell, but all I have
read about it (even from its proponents) directly supports you here.


> Common Lisp and C++ are interesting in that they support "staged
> programming" or partial evaluation directly in the language, via
> procedural macros and templates respectively.

Common Lisp macros are really a _lot_ more than this - there's nothing
partial about them.  They go far beyond the sort of thing you can do
with templates.  A CL macro is really just another CL program and can
do anything a "regular" program can do.  It can make use of any
functions, methods, other macros, etc.  What makes them so potent is
that they are invoked between the reader and the parser (in this they
are sort of like a "typical macro").  But since you have the full
capabilities of CL here, you can perform "unlimited" compile time
computations.  In particular, on the input stream.  You can do truly
stunning things with this.  You could write a C++ compiler with it
(well, as close as one can write a C++ compiler...) or the goofy
template language of C++.

One of the most typical is to write a domain or application specific
language for use in the "real" programs you are after (so that you can
express things cleanly, flexibly and at very high level), have it
compile down into optimized CL/CLOS, and then have this passed off to
the optimizing CL compiler.  This all happens transparently.  Of
course, you can also do this sort of thing "on the fly".  Upshot: you
typically never need any interpreter for anything, and you can express
solutions that mirror the problem space extremely closely (far closer
than with simple OOP), and the result always has the full advantage of
optimized machine code.


> Kinda cool, but I understand the Ada position on these features and
> how they impact maintainability.

The C++ template crap might be "kinda cool", but the CL macro
capability is pretty awesome.  Done "correctly", CL macros have a very
_positive_ impact on maintainability.

I agree it can be useful to keep the Ada position in mind; certainly
in the C++ case, the Ada way is a hands down winner.  Note that in the
CL case, you can at any point of use of a macro immediately: 1) see
what it yields and check if this is what you expect, 2) try it to see
if the result does what you expect.  Typically neither of these is
necessary.


> As I understand it, the consensus in the Lisp community is that
> macros are to be used sparingly.

I would say - used correctly, sparingly not being relevant.


I suppose this has gone far enough afield from Ada and we can
pretty much lay it to rest in this forum.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari