educating the educated
Benjamin Ylvisaker
reasonably be called "ML for Joe C Programmer"? I have read bits and
pieces of several fine introductory references to ML, but they all
seem to be more introductions to programming than introductions to ML
for experienced programmers. I am trying to convince the powers that
be at my company that we should build a project in ML and one of their
major concerns is the paucity of programmers trained in functional
languages (let alone an ML). I think it would be useful to have a
document that focussed on topics like, "Imperative programmers
implement data structure XYZ in this way, in SML you should implement
it in that way". Does such a beast exist?
Benjamin
ude.umc.inmula@ynimajneb
Jesper Louis Andersen
> Are there any books/papers/lecture notes/whatever that might
> reasonably be called "ML for Joe C Programmer"?
L.C. Paulson:
ML for the Working Programmer.
Cambrigde University Press
ISBN: 0 521 57050 6 (Hardback version)
ISBN: 0 521 56543 X (Paperback version)
Far the best i've read on programming ever. Its one of those books I
still get a pleasure out of reading 4 years after I bought it. Highly
recommended from my side.
--
Jesper
Jeffrey M. Vinocur
Benjamin Ylvisaker <sletv...@yahoo.com> wrote:
>Are there any books/papers/lecture notes/whatever that might
>reasonably be called "ML for Joe C Programmer"?
You might consider Paulson's text, ML for the Working Programmer.
--
Jeffrey M. Vinocur * jm...@cornell.edu
http://www.people.cornell.edu/pages/jmv16/
Scott Nightlinger
for and that it may not help but here are two urls for CAML and OCAML.
http://caml.inria.fr/
http://www.ocaml.org/
From what I understand, functional programming is more popular in Europe
than in America. And I have no idea where you are from. And what
importance any of that has, I do not know! :)
--
Scott Nightlinger
nigh...@students.uiuc.edu
There are only 10 kinds of people in the world:
Those who understand binary, and those who don't.
Scott Nightlinger
Re: [NEWBIE][HOWTO]How do I get started with the SML/NJ interface?
Check out the above thread in this newsgroup by Rowan Davies.
http://cm.bell-labs.com/cm/cs/what/smlnj/doc/
--
Scott Nightlinger
nigh...@students.uiuc.edu
There are only 10 kinds of people in the world:
Those who understand binary, and those who don't.
[2 <text/html; iso-8859-1 (quoted-printable)>]
Arthur Chance
> Are there any books/papers/lecture notes/whatever that might
> reasonably be called "ML for Joe C Programmer"?
[snip]
> I think it would be useful to have a
> document that focussed on topics like, "Imperative programmers
> implement data structure XYZ in this way, in SML you should implement
> it in that way". Does such a beast exist?
"ML for the Working Programmer" by L. C. Paulson, [Cambridge University
Press] is useful, although his definition of a working programmer
isn't quite the same as mine. (How many working programmers write
theorem provers? :-)
As a programmer learning ML after an imperative and OO background I've
found "Unix System Programming with Standard ML" by Anthony Shipman to
be very useful, and you get a small but working web werver as example
code to play with as well. It's available in both PDF and HTML and
there's a downloadable zip file of everything. You can find it via
http://web.access.net.au/felixadv/smlbook.html
--
What was it that sliced bread was the greatest thing since?
Thant Tessman
> [...] I think it would be useful to have a
> document that focussed on topics like, "Imperative programmers
> implement data structure XYZ in this way, in SML you should implement
> it in that way". Does such a beast exist?
From my own experiences learning Scheme and SML for myself, and
teaching coworkers, I recommend that you be careful with the above
approach. There really is no satisfactory analogy for the power of
higher-order functions in traditional imperative programming languages.
The bad news is that without an understanding of higher-order functions,
it is impossible to fully appreciate the advantage of a language like
SML. The good news is that, in my experience, once a person really does
get it, the advantage is obvious.
-thant
Thaddeus L Olczyk
So can you give a sample program on how this goes?
Thant Tessman
I wrote:
>>The bad news is that without an understanding of higher-order functions,
>>it is impossible to fully appreciate the advantage of a language like
>>SML. The good news is that, in my experience, once a person really does
>>get it, the advantage is obvious.
Thaddeus L Olczyk wrote:
> So can you give a sample program on how this goes
I assume you're asking about my experience advocating a functional
programming language on a commercial project.
My field is real-time 3D graphics, so I don't get much chance to use
languages other than C/C++. But my experience with other languages in
the commercial world is not zero. I've been lucky to see the lightbulb
go on a few times--once with a project lead who eventually chose Scheme
as a scripting language for a very complex virtual reality
implementation. And both Scheme and SML has proven themselves very
useful to me in situations where code sharing wasn't an issue. On the
other hand, I've also worked with people who are reluctant to use C++
over C, or have walked away from a demonstration of SML for no other
reason than the fact that the SML/NJ prompt is (in their eyes) a minus sign.
It seems that you can convince someone that a 'non-traditional'
programming language might be more productive only if they are the type
who are willing to first learn a new language merely for the fun of it.
-thant
Benjamin Ylvisaker
>
> From my own experiences learning Scheme and SML for myself, and
> teaching coworkers, I recommend that you be careful with the above
> approach. There really is no satisfactory analogy for the power of
> higher-order functions in traditional imperative programming languages.
> The bad news is that without an understanding of higher-order functions,
> it is impossible to fully appreciate the advantage of a language like
> SML. The good news is that, in my experience, once a person really does
> get it, the advantage is obvious.
>
> -thant
I think that's good advice. Perhaps it is better to think of the
problem as explaining how ML constructs and idioms might map back into
C or Java, rather than how C and Java idioms map into ML. Obviously
there are some ML constructs that don't map well into C or Java, this
is where an imperative programmer has something new to learn.
Thanks to everyone for recommending Paulson's book. I have not read
it, but the table of contents made me think that it might not be
exactly what I'm looking for (as Arthur's comment suggested).
Thanks to Scott for making me read that other thread again. I found
some interesting tutorials on the SML/NJ site that I had never seen
before.
Benjamin
Yoann Padioleau
let take a simple example, you need to add to each element of a list the number 3:
List.map (fun x -> x + 3) my_list
try do this in C and it will take far more line.
What is important is that any C program can be made 10 times shorter
when transformed in ocaml. (and 10 times clearer for an experienced programmer).
>
--
Yoann Padioleau, INSA de Rennes, France,
Opinions expressed here are only mine. Je n'cris qu' titre personnel.
**____ Get Free. Be Smart. Simply use Linux and Free Software. ____**
Yoann Padioleau
> >Thaddeus L Olczyk <olc...@interaccess.com> writes:
> >
> >> dOn 20 Sep 2002 17:02:00 GMT, Thant Tessman <th...@acm.org> wrote:
> >>
> >> >Benjamin Ylvisaker wrote:
> >> >
> >> >> [...] I think it would be useful to have a
> >> >> document that focussed on topics like, "Imperative programmers
> >> >> implement data structure XYZ in this way, in SML you should implement
> >> >> it in that way". Does such a beast exist?
> >> >
> >> > From my own experiences learning Scheme and SML for myself, and
> >> >teaching coworkers, I recommend that you be careful with the above
> >> >approach. There really is no satisfactory analogy for the power of
> >> >higher-order functions in traditional imperative programming languages.
> >> >The bad news is that without an understanding of higher-order functions,
> >> >it is impossible to fully appreciate the advantage of a language like
> >> >SML. The good news is that, in my experience, once a person really does
> >> >get it, the advantage is obvious.
> >> So can you give a sample program on how this goes?
> >
> >let take a simple example, you need to add to each element of a list the number 3:
> >
> >List.map (fun x -> x + 3) my_list
> >
> >try do this in C and it will take far more line.
> >
> >What is important is that any C program can be made 10 times shorter
> >when transformed in ocaml. (and 10 times clearer for an experienced programmer).
>
i dont think, maybe.
> Your specific example:
>
> int i;
> for(i=0;i<list_size;i++) { list[i]=list[i]+3;}
except that in my example i allocate a new list, i dont overwrite the original one.
you need to add malloc statement.
(seems i am not the only stupid man here)
and you need to do write length(list) in place of list_size
where length return the length of a list.
please put valid C code !!
>
> written for a generic function f
>
> int (*f)(int);
> int i;
> for(i=0;i<list_size;i++) { list[i]=list[i]+(*f)(3);}
??? your code is already not clear.
Thanks for proving my argument to be true.
>
> In C++
> foreach(list.begin(),list.end(),
> struct { int operator()(int){ return i=i+3;}());
> This only works with the upcoming stadard for a technical reason.
>
> for present C++ you need something like:
> for_each(list.begin(),list.end(),
> AnyUnaryOperator(
> struct:UnaryOperator<int,int>
> { int operator()(int)
> { return i=i+3;}())());
Thanks for proving my argument to be true.
>
> I grant that you need two classes AnyUnaryOperator and UnaryOperator,
> but they are ten lines, I defined them once 5 years ago and literally
> have used them hundreds of times.
>
> PS: These techniques allow for generalisation, I can for example only
> modify the middle third of the list.
>
> Any nonlanguage zealots out there who really understands the advantage
> of higher order functions?
are you that stupid to ask again ?
your example dont even manage to return a fresh new list, it
requires awful syntax, it requires 7 lines,
the advantage of higher order of function is to be generic. that is you save typing.
for example map is higher order, it takes a function as a parameter, so
you factorise one time for all, any code that have the form
for_each(list.begin(), list.end(), do_with_this_element(e))
your foreach is an higher order function (you dont even understand it)
In fact you can already do higher order function in C++ or even C
(even if the syntax is just painful)
A problem is that when you have higher order function, you often need
anynymous functions, and closures, which are not available in classic C/C++
(you can still use advanced library such as PETE or FACT, but i think that
the syntax is just awful)
Thaddeus L Olczyk
>
>
>I wrote:
>
>>>The bad news is that without an understanding of higher-order functions,
>>>it is impossible to fully appreciate the advantage of a language like
>>>SML. The good news is that, in my experience, once a person really does
>>>get it, the advantage is obvious.
>
>Thaddeus L Olczyk wrote:
>
>> So can you give a sample program on how this goes
>
>I assume you're asking about my experience advocating a functional
>programming language on a commercial project.
No. I am asking for a sample program. Can't you read, but then from
the rest of the post I can see that you are not very intelligent.
<clipped>A lot of shit about how great functional programming is but
all slogans no substance. </clipped>
Are there any people out there who are not language zealots who know
what they are talking about and understand higher order functions?
Thaddeus L Olczyk
>Thaddeus L Olczyk <olc...@interaccess.com> writes:
>
>> dOn 20 Sep 2002 17:02:00 GMT, Thant Tessman <th...@acm.org> wrote:
>>
>> >Benjamin Ylvisaker wrote:
>> >
>> >> [...] I think it would be useful to have a
>> >> document that focussed on topics like, "Imperative programmers
>> >> implement data structure XYZ in this way, in SML you should implement
>> >> it in that way". Does such a beast exist?
>> >
>> > From my own experiences learning Scheme and SML for myself, and
>> >teaching coworkers, I recommend that you be careful with the above
>> >approach. There really is no satisfactory analogy for the power of
>> >higher-order functions in traditional imperative programming languages.
>> >The bad news is that without an understanding of higher-order functions,
>> >it is impossible to fully appreciate the advantage of a language like
>> >SML. The good news is that, in my experience, once a person really does
>> >get it, the advantage is obvious.
>> So can you give a sample program on how this goes?
>
>let take a simple example, you need to add to each element of a list the number 3:
>
>List.map (fun x -> x + 3) my_list
>
>try do this in C and it will take far more line.
>
>What is important is that any C program can be made 10 times shorter
>when transformed in ocaml. (and 10 times clearer for an experienced programmer).
Are you realy that stupid?
Your specific example:
int i;
for(i=0;i<list_size;i++) { list[i]=list[i]+3;}
written for a generic function f
int (*f)(int);
int i;
for(i=0;i<list_size;i++) { list[i]=list[i]+(*f)(3);}
In C++
foreach(list.begin(),list.end(),
struct { int operator()(int){ return i=i+3;}());
This only works with the upcoming stadard for a technical reason.
for present C++ you need something like:
for_each(list.begin(),list.end(),
AnyUnaryOperator(
struct:UnaryOperator<int,int>
{ int operator()(int)
{ return i=i+3;}())());
I grant that you need two classes AnyUnaryOperator and UnaryOperator,
Jesper Louis Andersen
> Any nonlanguage zealots out there who really understands the advantage
> of higher order functions?
I call myself a language researcher at least, but I will still try to
answer your question. First of all, go read Hughes [1]. He talks about
why HOF is an advantage and gives plenty of good examples.
As for C(++) versus SML and others: You are right about it can be
implemented with function pointers. I find the syntax for this much
harder to read though. I know that is a subjective argument, but it
works for me.
My programming is built around HOF most of the time. The average C
programmer doesnt do this, although he could. What is the difference
between C and SML when looking at HOF then? Not much. Map, fold and
filter are all easily programmed in both languages.
If you are going to program in functional languages, its not the HOF I
find most important. Sure, its a nice concept having functions as first
class citizens. But the inferred typechecking, the lack of variables
and pointers and pattern matching are more valuable to me.
The difference between C and SML is present though. In C you use
pointers for passing around your HOF, whereas they are first class
citizens in SML.
[1] Why Functional programming matters:
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
--
Jesper
Thant Tessman
[...]
> As for C(++) versus SML and others: You are right about it can be
> implemented with function pointers. [...]
A higher-order function is a function that builds other functions. This
can be simulated to some degree in C++ using function objects, but
calling conventions, memory management, and other issues will always
cripple attempts at functional programming in C++.
-thant
Michael Bukatin
On Mon, 23 Sep 2002, Thant Tessman wrote:
> A higher-order function is a function that builds other functions. This
> can be simulated to some degree in C++ using function objects, but
> calling conventions, memory management, and other issues will always
> cripple attempts at functional programming in C++.
Could you make a comparision with Java (especially, if we would
augment it with a better preprocessor, so that syntax is less
annoying) ?
Juergen Ilse
Yoann Padioleau <Yoann.P...@irisa.fr> wrote:
>> >let take a simple example, you need to add to each element of a list the number 3:
>> >
>> >List.map (fun x -> x + 3) my_list
>> >
>> >try do this in C and it will take far more line.
Wrong. Also this is IMHO a bad example, which does not show the power of
functional programming.
>> >What is important is that any C program can be made 10 times shorter
>> >when transformed in ocaml. (and 10 times clearer for an experienced programmer).
This is IMHO also wrong. there are problems, which imply a "classic"
solution using imperativ programming.
>> Your specific example:
>> int i;
>> for(i=0;i<list_size;i++) { list[i]=list[i]+3;}
> except that in my example i allocate a new list, i dont overwrite the
> original one.
Right, but this does not really lead us to typical problem for which
a functional solutions seems to be the best one ...
IIRC there are some good examples in the ocaml-book i saw some time
ago. I think the power is not only to use functions as parameters to
function-calls (that is also possible in C) and that a function can
return a function (this is also possible in C, even if many C programmers
don't use this feature). A big advantage is IMHO the possibility of
"partly applied functions". A function taking 2 integers and return
an integer value can be seen (and will normally implemented this way)
as a function taking 1 integer and returning a function which takes
an integer parameter and returning an integer ...
If you pass 2 parameters to that function, the C version seems to be
very similar to the ocaml version, but if you pass only one parameter
to that function, that would be an error in the C version (resulting
in undefined behaviour), in the ocaml version, you get as return value
a funtion, that can be applied to diferent values (for example to the
elements of a list).
To use your example above:
let add = fun x y -> x + y in
List.map (add 3) mylist;;
If you want to implement this in C without simplification, you have
(even if add(int x, int y) is known at compile-time) to construct a
second function at runtime, which takes 1 parameter y and returns y+3
for each input value. Then you have to apply this function to every
list element. The construction of tis temporary function ist trivial
in ocaml (because you get it, if you pass only the parameter 3 instead
of 2 parameters to the function add) but rather difficult in C ...
> you need to add malloc statement.
Peanuts (and only a result of the missing automativ memory allocation
and garbage-collection in C).
> (seems i am not the only stupid man here)
> and you need to do write length(list) in place of list_size
> where length return the length of a list.
> please put valid C code !!
In C you can implement a list as a struct of an integer which gives the
number of elements and an array of list elements, so you can take this
element of the structure (the number of list elements) in comparision
with the loop-counter ...
>> written for a generic function f
>>
>> int (*f)(int);
>> int i;
>> for(i=0;i<list_size;i++) { list[i]=list[i]+(*f)(3);}
> ??? your code is already not clear.
This code *is* clear, but i think, the generic version should be something
like:
elem *apply_to list(elem *list; elem (*f)(elem), int count)
{
int i;
for(i=0;i<count;i++) list[i]=f(list[i]);
return list;
}
Note, that the notation (*f)(list[i]) ist only necessary in old style
K&R C, in C89, the simplier f(list[i]) works in the same way (also in C99).
In this example elem is the type of the list-elements (and should be defined
at another place of the program), also f is the funtion to apply to each
list element. The code is simple and clear (and if you don't think so,
the reason is, that you don't really know the C language ...).
>> In C++
>> foreach(list.begin(),list.end(),
>> struct { int operator()(int){ return i=i+3;}());
>> This only works with the upcoming stadard for a technical reason.
The "upcoming standard" is not upcoming but ready to use (even if there
are some compilers which don't implement the full standard).
>> Any nonlanguage zealots out there who really understands the advantage
>> of higher order functions?
I hope my example shows it in a better way (even if i am not an ocaml
programmer yet ...). If there are bugs in my example-source, the reason
ist, that i don't use ocaml regulary (and so, i don't know the syntax
good enough to avoid all errors ...).
> your foreach is an higher order function (you dont even understand it)
> In fact you can already do higher order function in C++ or even C
> (even if the syntax is just painful)
> A problem is that when you have higher order function, you often need
> anynymous functions, and closures, which are not available in classic C/C++
> (you can still use advanced library such as PETE or FACT, but i think that
> the syntax is just awful)
There are many people out there, who think that some elements of ml style
languages are really painful, it all depends on what you normally use (that
would be easier to read and easier to use for you, for some people C, for
others lisp and for some people ocaml ...).
Bye,
Juergen Ilse (il...@usenet-verwaltung.org)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglhen
lt. Es ist Duft, den man fhlt. Es ist ein Bild, das man riecht.
Es ist Erfllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Jeffrey M. Vinocur
comp.lang.functional if you want to continue. ]
In article <amnrdb$c42$1...@cantaloupe.srv.cs.cmu.edu>,
Jesper Louis Andersen <jlo...@diku.dk> wrote:
>
>My programming is built around HOF most of the time. The average C
>programmer doesnt do this, although he could. What is the difference
>between C and SML when looking at HOF then? Not much. Map, fold and
>filter are all easily programmed in both languages.
Yes, but anonymous functions aren't. Certainly not in C[1]. In
Java you *can* do anonymous classes and thereby pass around
objects wrapping a dynamically generated method, but it's not
exactly pretty.
Pascal did have inner functions, as I recall, but downward-only.
I don't know about C++ on this.
>But the inferred typechecking, the lack of variables and
>pointers and pattern matching are more valuable to me.
These are all good points. (You have no idea how many times I've
gotten compiler errors because my Java contains things like
"let x = 0".)
[1] Well, you *can* generate closures in C if you *really*
*really* want to. And your architecture is willing to
execute code off the heap. If this makes you more curious
than naseated, see
http://www.litech.org/~jeff/stuff/closures.c
Josh Stern
_Developing Applications with Objective Caml_, available on-line:
http://caml.inria.fr/oreilly-book/
From my point of view, a subset of the chapters in this book
provide a better answer to the question (holding the SML
vs. OCaml issue to one side) than the Paulson book (which
is a neat book for other reasons).
Regarding the question of the benefits of "higher-order programming",
I think there are at least three different point categories:
1) Code/library reuse - this point was already emphasized elsewhere
in the thread. What is required is the ability to pass functions
as arguments and store them. C/C++ have this feature, and
C++ STL is a good example of its use.
2) Logical organization of the code - just as with object-oriented
programming, where it is often desirable to define data structures
and the functions that operate on them in the same place, it
is desirable to be able to define helper functions in the
context of their use and to define their default/implicit
arguments in the context where those become known. These
organizational maneuvers are supported by lambda functions,
closures, and currying in ML, in a way that isn't possible to
do natively in C++, the most fundamental reasons being that
the language doesn't support composition of native executable
code within the language itself and it doesn't support storage
of native function bodies on the heap. I believe that it
is possible to build special class loaders and byte code compilation
libraries in Java/JNI that would do this, but there is no
direct support in the actual language and libraries for doing
so.
3) Convenient manipulating program bodies as data (sometimes called
having a meta object protocol) - possibly useful for re-engineering,
possibly useful for aspect oriented programming, probably useful for
meta-programming. There are a bunch of sub-features that could
be individually enumerated in this category. This is fully
supported in languages like Lisp and Prolog and less so
in other languages (almost not all in C).
-= Josh
Buday Gergely
> My programming is built around HOF most of the time. The average C
> programmer doesnt do this, although he could. What is the difference
> between C and SML when looking at HOF then? Not much. Map, fold and
> filter are all easily programmed in both languages.
What is the real difference is that C does not provide polymorphic type
checking and type inference for your code. It does help a lot in ML to
write working programs. In ML you can experience (and you will not learn
it by reading an example, you must try it) that first your program
typechecks it runs! This is quite not the case for C.
To the original poster: please be a bit less impatient.
- Gergely
Jesper Louis Andersen
> [ This is getting pretty off-topic; feel free to move it to
> comp.lang.functional if you want to continue. ]
Nah, ill just close the dicussion...
> Yes, but anonymous functions aren't. Certainly not in C[1]. In
> Java you *can* do anonymous classes and thereby pass around
> objects wrapping a dynamically generated method, but it's not
> exactly pretty.
Correct.
--
Jesper
Joachim Durchholz
>
> A higher-order function is a function that builds other functions.
That's not the textbook definition. At least not that of my textbook,
Hudak's "Haskell School of Expression", on page 56:
"[A] *higher-order function [...] is a function that can take one or
more functions as arguments or return a function as a result."
"fold" is higher-order by the textbook definition but not by yours.
Personally, I find that Hudak's definition is too strict; under
polymorphism, a function that returns the second element of a list is
"functional" in the sense that this second list element may be a
function. So I'd say that a function is higher-order if it either
applies a function passed in as a parameter, or constructs a function
that's returned as a result or as part of a result. This actually gets
closer to your definition, but there's still the difference in the
classification of "fold" as higher-order.
BTW this is getting mixed up constantly. People talk about higher-order
functions in your sense, but others don't use that definition and talk
about "fold".
Note that the "applicate a functional argument" part of higher-order can
be easily emulated in C, but the "construct a function" part requires a
lot of code in C. It's a pity that the "construct a function" aspect
doesn't have a good word for it. If there were terminology, the
confusion of what the term "higher-order function" means would go away.
(Or is there terminology, and most people - including me - are just
unaware of this?)
> This
> can be simulated to some degree in C++ using function objects, but
> calling conventions, memory management, and other issues will always
> cripple attempts at functional programming in C++.
That's very true.
BTW these issues tend to cripple OO programming in C++ as well (been
there, done that...)
Regards,
Joachim
--
This is not an official statement from my employer.
Joachim Durchholz
>
> Pascal did have inner functions, as I recall, but downward-only.
> I don't know about C++ on this.
C++ doesn't have inner functions.
Joachim Durchholz
> [1] Well, you *can* generate closures in C if you *really*
> *really* want to. And your architecture is willing to
> execute code off the heap. If this makes you more curious
> than naseated, see
> http://www.litech.org/~jeff/stuff/closures.c
The code is nonportable because C compiler and linker are free to
rearrange functions in any way that they wish.
I also think that pointer arithmetic on function addresses is undefined,
even after a cast.
Oh, and the code won't work if the compiler generates code with absolute
addresses.
But it's a cute idea anyway :-)
Thant Tessman
[...]
> Note that the "applicate a functional argument" part of higher-order can
> be easily emulated in C, but the "construct a function" part requires a
> lot of code in C. It's a pity that the "construct a function" aspect
> doesn't have a good word for it. [...]
[...in a hushed, reverent voice...]
lambda
-thant
Joachim Durchholz
Oh. Yes.
Some things are so obvious you forget about them.
Though it doesn't cover currying as a way of constructing functions.
(But the set of functions constructable via currying is finite, while
the set of functions constructable via lambda isn't even decidable. Or
did I overlook something again?)
Tomasz Zielonka
> Joachim Durchholz wrote:
>> Note that the "applicate a functional argument" part of higher-order can
>> be easily emulated in C, but the "construct a function" part requires a
>> lot of code in C. It's a pity that the "construct a function" aspect
>> doesn't have a good word for it. [...]
>
> [...in a hushed, reverent voice...]
>
> lambda
In papers about lambda calculus it is often called "function
abstraction".
> -thant
Regards,
Tomasz
--
.signature: Too many levels of symbolic links