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,fded8d14c74b14e5 X-Google-Attributes: gid103376,public From: Jon S Anthony Subject: Re: Looking for Ada Technique Name and References Date: 2000/03/01 Message-ID: <38BD7CE3.59CC@synquiry.com>#1/1 X-Deja-AN: 591907960 Content-Transfer-Encoding: 7bit References: <88kegp$iso$1@coward.ks.cc.utah.edu> <88kh6q$j4j$1@coward.ks.cc.utah.edu> <88s90i$8mi$1@ns3.arlut.utexas.edu> <88svc0$nkj$1@coward.ks.cc.utah.edu> <38b32dca@eeyore.callnetuk.com> <38B33F23.4784@synquiry.com> <38BA4C37.919935A8@earthlink.net> <38BB01F3.37BD@synquiry.com> <38BBF58A.ED345864@earthlink.net> <38BC3496.26FE@synquiry.com> <38BC73CC.54B8@synquiry.com> Content-Type: text/plain; charset=us-ascii X-Trace: client 951942416 38.151.18.1 (Wed, 01 Mar 2000 15:26:56 EST) MIME-Version: 1.0 NNTP-Posting-Date: Wed, 01 Mar 2000 15:26:56 EST Newsgroups: comp.lang.ada Date: 2000-03-01T00:00:00+00:00 List-Id: > 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