Think beyond "anonymous functions" -- go all the way and make functions first-class.  Then you have real power at your fingertips, a true functional language.  -M.

http://puma.wellesley.edu/~cs251/spring02/first-class-functions.pdf

That Wellesley CS professor's summary of first-class functions is not entirely correct.  (He skirts some issues for the sake of not confusing students.)

Microsoft's Vault site has a better discussion.  It warns, "The distinction between a Vault function and a C function pointer can be rather subtle."  The concept of closure is what counts here.

http://research.microsoft.com/vault/learn/tutorial/closures.htm

It is vindication for my point of view that Microsoft should adopt first-class functions in its version of "the next systems language" and I hope D does the same.

Mark

>Think beyond "anonymous functions" -- go all the way and make functions first-class.  Then you have real power at your fingertips, a true functional language.  -M. http://puma.wellesley.edu/~cs251/spring02/first-class-functions.pdf

Frequently Asked Questions for comp.lang.functional: http://www.cs.nott.ac.uk/~gmh//faq.html

Dan keeps talking about delegates.  This talk is dangerous.

Proper language design "compiles out" many legacy design patterns, and I recently posted links on that subject.  The pattern disappears when the language removes all need for it.  So describing a language in terms of the patterns it replaces is convoluted and confusing; it describes with something that no longer exists.  Instead, describe the language in terms of the features that do exist, and that replaced the patterns.  Terms like "closure" and "first-class function" are very standard.

Walter's remark about difficulty of implementation is worrisome.  D is a new language, and first-class functions should not be overly difficult, though they entail a good refactoring and redesign.  The kind of evolutionary dead-end suggested by Walter's remarks is exactly why I keep harping on the dangers of using C++ exclusively as a design foundation. It's critically important to think more generally than that; widen the gene pool with other languages.  You all know what happens when the gene pool is too small -- defects and extinction!

Mark

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b30vu9$np6$1@digitaldaemon.com...
> That Wellesley CS professor's summary of first-class functions is not
entirely
> correct.  (He skirts some issues for the sake of not confusing students.)
>
> Microsoft's Vault site has a better discussion.  It warns, "The
distinction
> between a Vault function and a C function pointer can be rather subtle."
The
> concept of closure is what counts here.
>
> http://research.microsoft.com/vault/learn/tutorial/closures.htm
>
> It is vindication for my point of view that Microsoft should adopt
first-class
> functions in its version of "the next systems language" and I hope D does
the
> same.

One point is the article saying that nested functions "capture" the value of variables in the enclosing environment at the point of declaration of the nested function. This is in contrast to pascal where the nested function directly references the enclosing stack frame.

Hi, Mark.

BTW, I've really enjoyed following all the links you've posted.  Very educational.  Keep it up!

I cut my baby programmer teeth on Lisp, which has first class functions.  Some people look at my code and say Lisp ruined me (too many small functions).  I also write a LOT of C, and some C++.

In all the C code I've written, I haven't missed Lisp's first class functions.  Not once.  I think they are an anceint concept (40 or 50 years now?) that may be evolving out of the gene pool.

I'm much more interested in some of the newer features being included in some of the languages you've dug up.  D already includes many of them. Two of the ones I believe I would actually use are:

- Powerful iterators.  I hate writing recursive iterators and passing callback functions to them.  Newer schemes like Sather's eliminate that.
- Modifying existing classes directly.  Nice does this, allowing additional methods.  Sather does this even better, allowing class code to be directly incorporated into a new class with arbitrary modifications.  That really rocks.  I'd use that all the time.

Bill Cox

Mark Evans wrote:
> Dan keeps talking about delegates.  This talk is dangerous.
> 
> Proper language design "compiles out" many legacy design patterns, and I
> recently posted links on that subject.  The pattern disappears when the language
> removes all need for it.  So describing a language in terms of the patterns it
> replaces is convoluted and confusing; it describes with something that no longer
> exists.  Instead, describe the language in terms of the features that do exist,
> and that replaced the patterns.  Terms like "closure" and "first-class function"
> are very standard.
> 
> Walter's remark about difficulty of implementation is worrisome.  D is a new
> language, and first-class functions should not be overly difficult, though they
> entail a good refactoring and redesign.  The kind of evolutionary dead-end
> suggested by Walter's remarks is exactly why I keep harping on the dangers of
> using C++ exclusively as a design foundation. It's critically important to think
> more generally than that; widen the gene pool with other languages.  You all
> know what happens when the gene pool is too small -- defects and extinction!
> 
> Mark
> 
> 

>I cut my baby programmer teeth on Lisp....
>I also write a LOT of C, and some C++.
>In all the C code I've written, I haven't missed Lisp's first class
>functions.  Not once.

Well McCarthy, the creator of Lisp, got some things wrong.
http://www.cs.brown.edu/courses/cs173/2001/Lectures/2001-09-21.pdf
It's also possible that you were never a good Lisp programmer.  I know plenty of
imperative (C, Pascal, FORTRAN) programmers who write code in functional
languages which reads just like their favorite native tongue.  The
expressiveness of a functional language is wasted on them.

I write "a LOT" of C and C++ too, but use other languages regularly, and often move between imperative and functional paradigms even within the same project. The difference in expressive power is quite staggering.  As a rule I would always prefer to write something in a higher level style as would any intelligent programmer.  It's just easier.  I refer you back to my colleague's remarks about OCaml, which offers first-class functions.  The computer science Ph.D.'s at Microsoft Research have incorporated first-class functions into Vault pursuing goals practically identical to D's.  They are right on the money.

>I think they are an anceint concept (40 or 50 years now?) that may be evolving out of the gene pool.

That's like saying the wheel is going out of style.  Here is a very interesting
productivity contest between Lisp, Java, and C++.
http://www.norvig.com/java-lisp.html
"His results show that the resulting Lisp programs ran faster on average than C,
C++ or Java programs (although the fastest Lisp program was not as fast as the
fastest C program), and that Lisp programs took less development time than the
other languages."

Walter wrote:
> One point is the article saying that nested functions 'capture' the value of variables in the enclosing environment at the point of declaration of the nested function.

That 'environment capture' is called a closure.  'Nested functions' are not the key idea, so worrying about stack frames is off the mark.  The nesting just arose because they wanted to show how FCF's permit precise scope control, i.e. no one but its caller needs visibility on that function.

The Needle language offers not only first-class functions, but first-class
continuations too.  Icon has the same idea, though I'm not sure it's truly
first-class.  It's been a while since I wrote Icon code.  Continuations are
probably over the top for D, but I can envision them helping with interrupt
service routines and multithreading.  A better starting point on multithreading
would be the Oz book which puts the entire subject in context.
http://www.nongnu.org/needle/
http://www.info.ucl.ac.be/people/PVR/book.html

Mark

In article <b3665m$2juo$1@digitaldaemon.com>, Mark Evans says...
>
>>I cut my baby programmer teeth on Lisp....
>>I also write a LOT of C, and some C++.
>>In all the C code I've written, I haven't missed Lisp's first class
>>functions.  Not once.
>
>Well McCarthy, the creator of Lisp, got some things wrong. http://www.cs.brown.edu/courses/cs173/2001/Lectures/2001-09-21.pdf It's also possible that you were never a good Lisp programmer.

Well, I probably don't rate as a great lisp programmer...  I once tried to get a group of engineers to use a Scheme interpreter I wrote to control a place and route tool I was working on.  Big mistake.  I junked it, and wrote a Basic interpreter instead which they actually used (this was before TCL).  Ever since, I've been weary of language features that confuse engineers.  Imagine trying to teach an average group of guys in the industry about tail recursion instead of loops, or continuations for error handling.

Can you give me a example of how first class functions can be used to improve an average programmer's productivity without confusing him or the poor guy who will inherit his code?

Personally, I think we do most programmers a favor by simplifying computer languages while adding a minimum of new features.  I love that Java doesn't have pointers, and that D discourages them.  I think all pointers, including function pointers and delegates, are like the C proprocessor: you don't really need them if the language provides the capabilities you were trying to emulate directly.

Bill

The author deliberates between C, C++, Java, OCaml, Scheme, Lisp.  Maybe I should have put the subject as "Re: OCaml" but that was getting tired.  -M.

http://www.paulgraham.com/vanlfsp.html

'Writing Java code, though not particulary painful in the sense that C is painful (core dumps etc.), puts me to sleep. Writing Ocaml ... is exciting. My motivation to tackle the project has tripled overnight.... Why are "languages designed for smart people" (LFSPs) so much more fun to program in than "languages designed for the masses" (LFMs)?'

Brief but informative slides on the proper compilation of function closures. -M.

http://pauillac.inria.fr/~xleroy/talks/compilation-agay.pdf